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

Re: WNPP now on the BTS

Hi Anthony et al,

 yes, I'm subscribed to -devel and yes, I saw your message the day you
 posted it.  Sorry about the delay.

 >> Anthony Towns <aj@azure.humbug.org.au> writes:

 > On Wed, Aug 02, 2000 at 10:28:22AM +0200, Marcelo E. Magallon wrote:
 > >  The tags to be used and corresponding severities would be:
 > >      O    important  The package has been Orphaned.  It needs a new
 > >                      maintainer as soon as possible.  If the package
 > >                      as a Priority of standard, required or essential,
 > >                      the severity should be set to grave.
 > What do you mean by "orphaned" here? The Maintainer field has been
 > set to "debian-qa@lists.debian.org"? Or that it should be moved to
 > project/orphaned?

 In the WNPP there are several packages tagged as 'Orphaned' and
 several tagged as 'Withdrawn'.  Some of the former have its
 maintainer set to Debian QA, some don't.  That's wrong.  According to
 the developers reference, all of them should have its maintainer
 field set to Debian QA if they are really orphaned.  The second tag,
 'Withdrawn' is used by WNPP for packages that are now in

 Right now, the following packages are tagged as orphaned and are not
 present on the distribution:

 dunc (it's in stable)
 icq-java (it's in stable)

 of those, only 9term and 9fonts are really in project/orphaned.
 > Why should this be anything more than a normal bug?

 Because they are not being actively maintained.  If a security
 problem arises with one of them, the security team will either make
 an upload to fix the problem or pull the package.  Other than that,
 the maintainance is nil.  You can't realistically expect the QA team
 to maintain... /me looks... 70 packages.  Yes, I know, in some cases
 the packages are bug free and there's no reason to pull them out, but
 I even so it's dubious that such a package will follow upstream

 Iff the package is really in good shape, then downgrade this.  If
 not, someone either has to take it or move it to project/orphaned,
 where there are no binaries but only source packages.

 > "important", "grave" and "critical" bugs generally mean a package
 > needs to be removed from the distribution. Orphaning a package, in
 > the normal case, doesn't imply this. Does it?

 IMO, yes.  Again, if these were just a couple of packages, that'd be
 ok, but if the number keeps increasing then this becomes a problem.
 If orphaned packages are just 'normal bugs', noone will pay attention
 to them arround release time, that is, we get to release packages
 without maintainers really backing them up.

 I searched the archives for the discussion that led to the current
 policy of assigning orphaned pakcages to Debian QA, but couldn't find
 it.  I don't really understand the rationale of having some packages
 in project/orphaned and some in the distribution.  I guess the ones
 in project/orphaned are the ones too buggy to keep in the
 distribution, which would automatically downgrade all the current
 orphaned/important bugs.

 Now, about the packages marked as orphaned in the WNPP database but
 without Debian QA set as its maintainer, I think that is a real
 problem now.  Either the information is wrong, or the package is not
 maintained at all.  Those are:

   xmorph gqmpeg archie eggdrop hx sac simh simh-rsts-images
   simh-unix-images sliplogin dip visual-tcl gnotes acs upsd cdwrite
   chameleon wmsysmon sc xarchie yard mysql-manual dbf2pg
   browser-history procmail-lib rel gambc scsh tama wmmail csh cgiwrap

 (In case anyone notices, wmmail is mine, I'll change the
 severity/retitle -- it's being maintained, but I'd like someone else
 to maintain it)
 > In addition, there doesn't seem to be any real point making any of
 > these bugs "grave". They don't in and of themselves make the system
 > unusable, or cause data loss, or introduce security holes.


 > I'd suggest having packages maintained by -qa be a "normal" bug,
 > unless they're standard or above in which case perhaps "important"
 > could be justified.

 Ok, sounds good.  What about those orphaned and not marked as being
 maintained by Debian QA?  I'd say once Debian QA takes over the
 package (that is, once that information is in the Packages file), the
 severity can be downgraded.
 > I'm not entirely sure how a release-critical bug could be justified
 > for this though. What package should be removed in the event of
 > such a bug? What if no one steps up to maintain it, but it's
 > otherwise completely bug free?  Should we never release?

 See above.
 > It might be useful, by contrast, to mark the bug as "important" if
 > the package should be removed from the dist and placed in
 > project/orphaned. I'm not sure why the bug shouldn't be filed
 > against the package itself in that case though.

 Because the package maintainer is not going to fix it, is he?  (I
 thought moving to project/orphaned implied bugging ftp.d.o)

 > >      ITO  important  The current maintainer of the package has stated
 > >                      his Intention To Orphan it.  The package is being
 > >                      maintained, but perhaps not in the best possible
 > >                      way due to lack of time, resources or something
 > >                      similar.  The package needs a new maintainer.
 > >      WTO  wishlist   The current maintainer Wishes To Orphan the
 > >                      package.  He's currently maintaining the package,
 > >                      but wishes someone else would do that.  This is
 > >                      different from ITO in the sense that if noone
 > >                      steps up and adopts this package, the world as we
 > >                      know it won't come to an end.

 > Really though, what's the difference between these two things? The
 > jump from a "wishlist" bug to an "important" one is pretty severe,
 > for something that doesn't seem to have a definable difference. I
 > notice there don't seem to be any WTO's there at the moment.

 There aren't because this is the one bit I sorta made up between
 feeding the BTS and writing the email you replied to (I didn't really
 made it up, this is just packages offered for adoption -- the tag is
 simply not in the WNPP database).  After feeding the BTS I got mail
 from a couple of people stating that they really didn't /need/ to
 orphan the package but it would be better if someone else maintained
 it (see for example comment about wmmail -- I'm not really using it
 anymore).  Upon second reading, I think I coredumped at this point.
 This should have been: O -> important (the package /is/ orphaned),
 ITO -> normal (the package /will be/ orphaned unless someone
 expresses his intention to adopt it in a short time) and WTO ->
 wishlist (it's somewhat possible that the package gets ITOed and/or
 Oed at some point)

 If everyone agrees I can fix this for the Developers Reference.

 > >      ITP  normal     Someone Intents To Package this.  Please submit a
 > >                      package description along with copyright and URL
 > >                      in such a report.
 > This will make those go to wnpp@debian.org rather than
 > debian-devel@lists.debian.org. Is this a good thing? Should the
 > former be gated to the latter?

 AFAIU, that's the idea, it doesn't look like that has happened yet.
 > It'd make more sense to me to have:
 > 	wishlist:	RFP, ITP, ITO, ITA, W
 > 	normal:		O
 > and maybe:
 > 	important:	O(>=standard)

 I guess I just have to wait and see what other people think.
 > >      W    adopt the package, upload to the main archive and close this
 > >           bug once the package has been installed.  If you are going  
 > >           to do this, retitle the bug with 'ITA:' + the old title.
 > >           This is necessary in order for other people to know the
 > >           package is being adopted.
 > What happens if/when the package is removed from project/orphaned?

 The bug is closed?
 > A lot of this stuff should probably be automated. When a package
 > gets installed in unstable, any appropriate RFP/ITP's don't have
 > any reason to be open anymore.

 That's exactly the idea.  This happens if the maintainer uses
 'Closes:' properly.  Also valid for ITAs.

 > If a package gets RFP'ed or ITP'ed multiple times, the reports
 > should probably be merged.


 > If a package gets uploaded with the maintainer set to debian-qa (or
 > changed from debian-qa to someone else), an appropriate O report
 > should probably be opened (or closed, resp.).

 Agreed.  The bit about orphaning (moving from 'person' to 'Debian
 QA') is the one that needs changing dinstall.  The other way arround
 can be handled using 'Closes:'.



Reply to: