NEW POLICY ANNOUNCEMENT...was (Re: new upload procedure approved)
On Wed, 28 Jan 1998, Christian Schwarz wrote:
> It's really silly to say that `I'm refusing to post any information in a
> timely fashion.' I spend _several_ _hours_ a day to organize different
> policy topics/decisions. Writing all the summaries, preparing HTML pages,
> sending bug reports, getting background (i.e., technical) information,
> answering all emails, takes a lot of time. Believe me, I'm trying to do my
> best to make it as easy as possible for those developers that don't have
> the time to follow all discussions in detail. But if you don't even have
> the time to read my summaries, I simply can't help you.
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.
>
> If you are really intrested in this topic (new upload procedure) I suggest
> that you check out the bug tracking system, Bug#17525. With the nice WWW
> access of the bug system, this just takes a few seconds--much less than
> this (worthless) discussion.
Maybe for you...just getting Netscape up and pointing to the bug reports
takes about 5 minutes, not to mention the time to load and hunt through
the bug reports. As a result, I don't web surf.
What has made this discussion worthless is your replies. It isn't too much
trouble for you to quote headers to mail messages, but it is to hard for
you to quote content?
The following is all that I was asking for, and thanks to your limited
willingness to communicate (from the headers you included) I was able to
find 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)
----------------------------------------------------------------------------
Topic 12: New upload procedure
STATE: APPROVAL
We've developed a new upload procedure on debian-policy and debian-devel
some time ago (in Nov 97, I think). The major change is that bug reports are
closed by a script on master after the upload has been processed.
Here is a list of the major changes since my last posting on this topic:
* Changed `closes' and `closed' term into `fixes'
(This has been suggested by a few people. Please tell me if `closes'
would still be preferred.)
* Relaxed syntax of pattern which detects `fixes' lines: spaces are
allowed in some places, pattern is case-insensitive, "bug" can be
omitted
(I don't think there is a risk that maintainers will accidentially
close bugs. If this should happen, the bug can always be reopened
again. There is one other problem, though: Since spaces are allowed, it
could happen that the editor "wraps" long lines into two. This will
_not_ be handled by the script, which means that some fixed bugs will
stay open. Again, actually no big problem.)
So, here is the current proposal. If noone objects I'll report this as a
`wish-list' bug report against ftp.debian.org and dpkg to get it
implemented.
Any comments are welcome! (But please consider that this topic has been
discussed in detail already.)
(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
-----------------------------
Maintainer's part:
1.) [Only for new packages:] discuss the package on debian-devel
2.) Upload package to master, chiark, erlangen, whatever
dinstall's part:
3.) [check for new packages 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):
/fixes:\s*(bug)?\#\d+\(,\s*(bug)?\#\d+\)*/i
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 <coyote@debian.org> Wed, 29 Oct 1997 14:22:37 -0600
The new updated parsechangelog/debian script will check for these
markers and insert a new "Fixes:" field into the .changes file:
Format: 1.5
Date: Wed, 29 Oct 1997 14:22:37 -0600
Source: foo
Binary: foo
Architecture: source all
Version: 1.0-5
Distribution: unstable
Urgency: low
Maintainer: Wile E. Coyote <coyote@debian.org>
Fixes: 98765 98766 99999
Description:
foo - Foos and Bars
Changes:
foo (1.0-1) unstable; urgency=low
.
* Recompiled with libc6, fixes: Bug#98765, Bug#98766
* Removed `rm -rf /' from postrm script, fixes:bug#99999
Files:
66909c6d1adc62c961f0618bb58fd2b5 194 doc extra foo_1.0-5.dsc
c4b3cabd889396dcf5251e0ea529bea7 983 doc extra foo_1.0-5.tar.gz
6d653b5f4dffd6e45109380e86dfe4e6 1038 doc extra foo_1.0-5_all.deb
When dinstall discovers a source upload which contains the `fixes:'
field it closes the 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>
To: <nnn>-submitter@bugs
Bcc: <maintainer from changes file>, <nnn>-close@bugs
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:
<path/to/binary/package>
<path/to/source/package>
#if NOT_INSTALLED_INTO_STABLE
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
Debian distribution.
#endif
A summary of the changes between this version and the previous one
is attached.
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
pp.
<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>.)
<.changes entry>
----end-of-email----
Additional notes
----------------
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".
2. Before sending the announcement of the package upload, dinstall
will check the maintainer's home directory on master if it contains a
`~/.changes-template' file, in which case the file contents will be
included at the top of the announcement message.
The file could look like this:
-----cut-here-----
Hi folks!
as usual you'll find this package also in ftp://ftp.my.site/my/dir/
-----cut-here-----
----------------------------------------------------------------------------
Later,
Dwarf
--
_-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: