[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NEW POLICY ANNOUNCEMENT...was (Re: new upload procedure approved)



[snip]
> 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
way.

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
that way. 

[snip]
> 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...


Cheers,

Chris

---------cut-here---------------------------------------------------------


>From schwarz@monet.m.isar.de Wed Jan 28 19:34:55 1998
Date: Mon, 26 Jan 1998 21:53:49 +0100 (CET)
From: Christian Schwarz <schwarz@monet.m.isar.de>
To: Debian Bugs <submit@bugs.debian.org>
Subject: new upload procedure


Package: ftp.debian.org
Severity: wishlist

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.


Thanks,

Chris

----------cut-here---------------------------------------------------------

     (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 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):

           /fixes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/i

     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 <coyote@debian.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
     file. 

     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>
       To: <nnn>-submitter@bugs.debian.org
       Bcc: <maintainer from changes file>, <nnn>-close@bugs.debian.org
       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----

     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
     for NMU's.)

     


     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".

     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         schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux?    schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
      
Visit                  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.debian.org   http://fatman.mathematik.tu-muenchen.de/~schwarz/


--
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: