Re: NEW POLICY ANNOUNCEMENT...was (Re: new upload procedure approved)
> My question is, "Why are you going out of your way to be so difficult?", I
> only asked that your annoncement have some information content.
> If you are trying to "put me in my place", it isn't working.
I apologize if my last mail was a bit too `harsh'. It was not meant that
Perhaps this discussion resulted from a view misunderstandings: The first
proposal (policy weekly #5--that's the text you quoted) and the addendum
(results from policy weekly #5) both have been posted to debian-devel.
Since the final "bug report" just contains the changes worked into the
text I thought posting it to debian-devel would be a waste of bandwidth
since everyone here should already know the proposal and those that are
really intrested in the details could as easily check out the bug
report--that's the second misunderstanding from my part: I thought it is
easy for everyone to read bug reports.
So, I'm sorry for the way I reacted. Perhaps I should have simply posted
the proposal to debian-devel after you requested it. Next time, I'll do it
> So, for those like me who just want to know what happened, I am quoting
> section 12 (out of 16) here for their benefit. (Sorry if this is
> offensive to you)
It's definitely not offensive to me--but unfortunately, you are quoting
the old version here. Your text is from policy weekly #5, but there have
been some changes (part of the `results from policy weekly #5' posting).
To get everything right now, I've attached the current proposal below.
That's also included in bug report #17525--if someone has any technical
notes/objects etc. WRT the new upload procedure, please CC: the replies to
the bug tracking system.
Hope this is ok for everybody now...
>From email@example.com Wed Jan 28 19:34:55 1998
Date: Mon, 26 Jan 1998 21:53:49 +0100 (CET)
From: Christian Schwarz <firstname.lastname@example.org>
To: Debian Bugs <email@example.com>
Subject: new upload procedure
We've developed a new upload procedure on debian-policy and
debian-devel in the last weeks. Here is the final proposal. I haven't
received any objections yet, so I consider this approved.
If you have any questions, please drop me a note.
(Note, that `dinstall' is the script on master which processes all new
uploads and installs them in the Debian ftp directory.)
Procedure for package uploads
1.) [Only for new packages:] discuss the package on debian-devel
2.) Upload package to master, chiark, erlangen, whatever
3.) [check for new packages about every ten minutes]
Check if package upload was complete and the files are correct
(i.e. check PGP signature, MD5 sums, correct .changes file, etc.)
If there is an error send mail to the maintainer and stop
4.) Send announcement to debian-devel-changes in case of an "unstable"
or "experimental" upload
5.) [once a day]
Install packages into the archive
(In case of a new package or a stable upload, this requires the
acknowledgement of the archive maintainer)
6.) Send announcement to debian-changes in case of a "stable" upload
7.) [For source uploads only]
Close bug reports that are fixed with this package upload
(see below for details).
Details about how bug reports are closed
With the new upload procedure, bugs will usually be closed by the
dinstall script, not be the maintainer. This has the advantage that
the maintainer has less work to do and that the bug reports get closed
only after the package has been installed in the ftp
server. (Currently, most maintainers close the bugs after having the
package uploaded. Sometimes, it takes a long time until the package
gets actually installed and some users which still use the old version
might file the bug report again...)
So, if a package upload fixes some bugs, the maintainer should include
some tags in the debian/changelog file that use the following syntax
(Perl regexp syntax, case-insensitive):
The pattern may also be wrapped over a few subsequent lines.
Here is an example for those that do not speak Perl:
foo (1.0-5) unstable; urgency=low
* Recompiled with libc6, fixes: Bug#98765, Bug#98766
* Removed `rm -rf /' from postrm script, fixes:#99999
-- Wile E. Coyote <firstname.lastname@example.org> Wed, 29 Oct 1997 14:22:37 -0600
In contrast to previous proposals, dpkg-genchanges will _NOT_
parse the changelog entry and include a Fixes: field in the .changes
dinstall will parse the changelog entry and search for `fixes:'
fields. In addition, dinstall will determine whether the upload
is a maintainer upload (MU) or a non-maintainer upload (NMU) by
comparing the email address from the changelog entry to the
maintainer email address listed in the .dsc control field.
In case of a MU, dinstall will closes all listed bug reports by
sending messages of the following form to the bug tracking system:
(Note, that the message header is quite important. It must appear to
come from the developer submitting the package, so that the bug system
sends its notifications &c to the right place, and it must make sense
to the user.)
From: <maintainer from changes file>
Bcc: <maintainer from changes file>, <nnn>-email@example.com
Subject: Bug#<nnn>: fixed in <package> <version>
We believe that the bug you reported is fixed in the latest version
of <package> (<version>), which has been installed in the
Debian FTP archive as:
NB that this package is not part of the released stable Debian
distribution; it may have dependencies on other unreleased software,
or other instabilities. Please take care if you wish to install it.
The bugfix will eventually make its way into the next released
A summary of the changes between this version and the previous one
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <nnn>@bugs, and the
maintainer will if appropriate reopen the bug report while your
concerns are addressed.
Debian distribution maintenance software
<maintainer from changes file> (supplier of updated <package>)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <contact address>.)
As soon as the new `fixed' bug severity has been implemented, dinstall
will reassign the severity of the bugs listed in the changelog entry
to fixed, for NMU's. (Until then, dinstall should skip closing bugs
1. With the current proposal, bug reports are only closed for source
uploads. (That's important since we don't want our bugs being closed
several times, once for each architecture :-)
However, some bug reports may be architecture specific. In these cases,
the bug reports have to be closed by the maintainer "by hand".
dinstall will look for `source' in the `Architecture' field of the
.changes file to detect source uploads.
2. In contrast to previous proposals, dinstall will _not_ check for
a file `~/.changes-template' in the maintainer's home directory on
master. (Including additional text in upload announcements should be
done via dpkg-genchanges.)
3. When dinstall sends the package announcements to the *-changes
lists, dinstall set the `From:' header to list the person doing the
upload, not something like `dinstall@master'.
4. dinstall currently sends a short message to the person doing the
upload once the packages are installed. This message should be extended
to list any closed/reassigned-to-fixed bug reports.
5. Currently, dinstall can be run on master with an additional option
to test whether the uploaded files will be installed without problems.
This test-only option should be extended to list the actions that will
be performed on the bug reports listed in the changelog entry.
-- Christian Schwarz
Do you know firstname.lastname@example.org, email@example.com,
Debian GNU/Linux? firstname.lastname@example.org, email@example.com
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .