On Sun, Aug 06, 2000 at 12:13:09AM +0200, Marcelo E. Magallon wrote:
> 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.
Agreed. They should be changed to ITO, or reuploaded by debian-qa with
the proper Maintainer: field, I presume.
> > Why should this be anything more than a normal bug?
> Because they are not being actively maintained.
So? Release critical bugs mean we a package is unsuitable for release. It
doesn't mean "hey, this is important, look at it!". It means remove this
package. It doesn't, in general, mean "hold up the release 'til this is
fixed", either, no matter how people have been treating it.
So, really, either the bugs should be downgraded, or every single on
of those orphaned (or, atm, ITO'ed) packages should be (and will be)
removed from the distribution.
I don't think there's any good reason to remove them, personally. Take
`silo' for example. Okay, it's orphaned. Shall we remove the package? If
so, we presumably better remove binary-sparc as well. Is that really a
desirable situation to put ourselves in?
> 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.
If the packages are in good shape, there's no reason to pull them. If
they're not in good shape, there's *already* a reason to pull them.
> > "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.
Again, trying to get people to pay attention to them is *not* a good reason
for setting their severity incorrectly. If you want people to pay attention
to them, post summary lists to -devel-announce, sorted by priority, and give
reasons why people would want to adopt them.
Orphaned Packages (will be withdrawn!)
blah (2 grave bugs! 50 normal bugs; 20 wishlist bugs)
Orphaned Packages
foo (10 normal bugs; 15 wishlist bus)
.
.
.
(or something). And in any event, if people don't want to pay attention to
them, well, that's their buisness. Volunteers, &c.
> 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,
Largely, yes.
> 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.
So they probably should all just be changed to `ITO', and mail the
maintainer to see if they really meant to have changed the Maintainer:
field by now.
> > 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)
Nor is the wnpp maintainer.
Note that when a package is going to be removed from the dist, there's
two real options: either fix the bugs, or get ftpmaster to mv the .deb's
and such. Sometimes there may be too many bugs to fix in a reasonable
amount of time and effort, but it's *still* a possibility.
> 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)
Again, I fail to see the real difference between ITO and WTO. Okay,
one has a time limit, and the other doesn't. So the former *will*
take two weeks, and the latter might only take one. Or it might take
four. Or fifty. Either way, until it's actually orphaned, it's still
being maintained, so there aren't any *actual* problems 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.
> > 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.
That's not automatic :) As soon as the package foobar_X-Y.deb is in the
distribution, a bug entitled:
ITP: foobar
RFP: foobar
O: foobar
can be closed. If the Maintainer: field changes between foobar_X-Y and X-(Y+1),
then:
ITO: foobar
and WTO: foobar
can either be closed, or changed to O: foobar (depending on whether it was
set to -qa or not). If the bugs didn't exist, then a new O: foobar bug should
be automatically filed.
> > 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:'.
Huh? You don't need to change dinstall to do this.
First, generate a database of the current maintainers:
zcat unstable/*/source/Sources.gz |
awk '/^Package:/ {P=$2} /^Maintainer:/ {M=$0; print P, M}' |
sed 's/Maintainer: //' | sort > maintainers.curr
then wait a while, rename the above to maintainers.old, and get a new
maintainers.curr list.
You can then, eg, find the packages that've been taken over by -qa,
diff maintainers.old maintainers.curr | grep "^>.*debian-qa" |
sed 's/^> //;s/ .*$//' | column
or the one's that used to be handled by -qa but aren't anymore:
diff maintainers.old maintainers.curr | grep "^<.*debian-qa" |
sed 's/^< //;s/ .*$//' | column
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpMaCmjFZJJ0.pgp
Description: PGP signature