Re: testing and no release schedule
Adrian Bunk wrote:
> The many package removals are not something I'm a fan of.
> During the potato freeze, it was always clear which package might be
> removed long before.
Well, let's try to make it clear....
If source package X has an RC bug open against it (or any of its binary
packages) for more than a month, and it can be removed (i.e. it's not at
the bottom of an enormous dependency chain), then it probably will be.
I may have the length of time wrong (a month), but that's what I've been
going with. If someone more informed than I cares to mention the actual
rule of thumb being used, that would be great.
> With testing, packages get removed every day because their maintainer is
> lazy or MIA (which says nothing about whether there are users requiring
> this package)
Yes, but it does say something about whether the package is "too buggy to
support". :-P
> or even only to make a library transition possible.
I believe that the intent was to restrict that to library transitions which
fixed "more important" RC bugs.
> I'm not concerned about "very important" packages like Gimp. I'm more
> concerned about one package here and one package there like users are
> asking "Why is gnuchess not in Debian 3.0?". I have sometimes the
> impression removing packages should in some way punish the maintainer.
No, that's not the purpose.
> But in the end it only punishes the users of Debian,
And it doesn't punish the users to have unacceptably buggy packages? That
is what RC bugs are supposed to mean, after all.... given the choice
between including a package with a (real, not inflated) grave bug and
leaving it out, I think it should be left out, and I daresay a lot of
people agree with me.
> and this in turn
> punishes Debian.
No, it increases the quality of Debian (while reducing its size). It's a
blunt instrument, but when maintainers won't fix RC bugs and nobody else
will NMU them, what should the release managers do? Surely you don't
expect them to personally fix all the RC bugs, mostly in packages they have
no knowledge of or interest in?
> Things are even worse if packages that might require security fixes and
> that were present in earlier stable releases are no longer present
> since this could result in people silently loosing security upgrades
> (when doing a dist-upgrade you don't notice if a few packages aren't
> upgraded).
Um. Perhaps it should be suggested that, after upgrading, people run that
command which detects packages not from the current release, and remember
to check those for security issues? (What was that command?...)
> In potato there was one such case (smail), and it was
> explicitely covered in the release notes.
>
>> > Fixing bugs is not very effective as long as
>> > there'a no freeze and new upstream versions with new bugs flood into
>> > testing every day.
There is an issue here: People should not be uploading new upstream
versions constantly, just for the upstreaminess of it. (Although new
upstream *bug-fix* or stable-release versions might be considered generally
safe enough to upload.) I think most Debian Developers are actually
behaving themselves in this regard.
Anyway, most of the RC bugs right now are basically packaging bugs.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
Reply to: