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
project/orphaned.
Right now, the following packages are tagged as orphaned and are not
present on the distribution:
dpkg-scriptlib
silo
dunc (it's in stable)
icq-java (it's in stable)
9fonts
9term
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
upgrades/bugfixes.
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
guile1.3-doc
(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.
Granted.
> 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.
Yes.
> 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:'.
Thanks,
Marcelo
Reply to: