Re: WNPP now on the BTS
>> Anthony Towns <aj@azure.humbug.org.au> writes:
> > > 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.
Ok, I see your point. Basically the question is if an orphaned
package is unsuitable for release. IMO, the answer in the generic
case is yes. Again, iff the package is in good condition, then I
think it's ok to release it like that. If the package has some
ammount of bugs or is important, I don't think it's reasonable to
release it like that. In any case, either downgrade or ignore the
bug.
JFTR, this is how orphaning packages works right now (or how it's
supposed to work right now):
http://qa.debian.org/documentation/qa.html/ch-rules.html
> 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.
Agreed.
> 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?
I was pretty surprised when I saw silo was orphaned. In particular,
#56500 and #65659 sound bad (they are in fact the same bug). The BTS
says Davide Barbieri maintains silo. http://packages.debian.org/silo
doesn't know anything about silo. The sparc Packages file agrees
with the BTS. silo is important (priority, not personal judgement)
So. Yes, IMO we shouldn't release the distribution without silo
having a maintainer.
> 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.
Ok. Working on that, too.
> 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.
This one seems to be a problem of how to name this. It's a plain old
'Up for adoption'/'Looking for new maintanier'. "I don't want do
orphan it, I just want someone else to maintain it because I'm not
using this anymore but I think it's useful for other people or
whatever." What do I call that?
> 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.
When Shaleh proposed using the BTS for WNPP the intention was clear:
use a tool all the developers are familiar with, is already in place
and is already automated as possible and already integraded with
other tools in debian (dpkg-genchanges, dinstall, ...). The bugs are
filed against a special package, wnpp, because it doesn't make sense
to file bugs against non existing packages (RFP, ITP), or doesn't
make sense to file bugs against the pacakge itself (WTO, ITO).
As you say, looking for a new maintainer is not a problem. It's
filed against WNPP in order for other people to see this. Yes,
wnpp@debian.org needs to redirect ITPs, WTOs, RFPs and ITOs to
-devel to improve visibility.
> > > 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 :)
Then I misunderstood what you meant by automatic.
I see a RFP bug. I package the program. In the changelog I add
(Closes: bug#100000). I upload. dinstall installs the package on
the archive. The bug is closed. Do you want more automatic than
that? (The same is valid for ITPs, WTOs, ITOs, Os and Ws when
adopted)
> 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.
By whom/what?
> > 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
^^^^^^^^^^^^^^^^^
aha.
Ok, this should be enough. BTW, package orphaning is already
automated. See: http://qa.debian.org/maintainer.html
Downgrading/retitling from O: to W: (or similar) should also happen
automatically. project/orphaned is not the happiest of the places,
but I guess I can do that, too.
Now I'm downgrading the ITOs to normal...
Cheers,
Marcelo
Reply to: