On Mon, Jun 02, 2008 at 11:16:51PM +0000, Mike Bird wrote:
> On Mon June 2 2008 17:38:53 Lucas Nussbaum wrote:
> > On 02/06/08 at 15:04 -0700, Mike Bird wrote:
> > > "Don't create 20-day removal hints for packages with RC bugs
> > > except when its too late for a fix to be included in the
> > > forthcoming release".
> >
> > Your proposed solution doesn't allow testing to converge to a releasable
> > state. The only solution you are offering is "do nothing".
>
> Lucas,
>
> The current 20-day policy only applies to "leaf" packages. I don't
> know which definition of "leaf" is intended, so let's assume that
> it refers to packages referenced in Pre-Depend, Depends, and
> Recommends but not Suggests, as that roughly matches aptitude's
> default behavior.
A leaf package is a package that is not part of any {pre-,}depends
line.
> Of approx[1] 21828 Lenny packages which we track, approx[1] 10514
> or 48% are non-leaf and therefore excluded from the current 20-day
> policy. (If Suggests dependencies are included the latter figure
> rises to 12786 or 59%).
Actually that's wrong, because there are packages that are part of a
Depends that are leaf package for me: e.g. when a library has a unique
r-dep, it's as if it was part of this r-dep and I consider it leaf. But
that's almost nitpicking.
Also there are a few packages that wont be removed that way, because
it would too hard to make them enter testing again (I assume iceweasel
is a leaf package, it's already hard to make it transition usually,
let's do not remove it). But those exceptions are few, and must be,
because those have to be special cased and it doesn't scale.
> The RC-bugs-in-testing metric is actually a better metric for
> not artificially excluding RC bugs from testing.
Why "artificially" ?
> The principal goal remains that Testing should be usable for new
> desktop installations for most of the release cycle.
No it's not. The principal goal of testing is to evaluate what would
be our next stable if we tried to release *RIGHT NOW*. Packages with RC
bugs cannot be part of a release, so must be kept out. *I* don't really
care about testing being fully usable all the time, I care about it
being a good representation of what could be released. Testing was meant
as a release management tool, not really as a usable distribution.
People happen to use it, but (1) I often discourage this to people I
talk to (2) there are people that care about testing being usable,
that's why testing-security and t-p-u exists. Talk to them, those are
the guys that are interested in fixing packages before we actually
remove them from testing. I work from this URL [0] (I posted it already
several times btw), there is around 100 bugs, it's quite easy to have a
look at it, and to see if there is something worth saving in the
list[1]. But that's not our job[2].
I'd like to add a thing that you miss totally and that doesn't make
this "artificial" at all:
* We do *NOT* remove packages that are fixed in sid and not yet in
testing. Our job here, is to try to make packages that are fixed in
sid and not in lenny migrate. It's a bit too soon to start that for
each package, but it's what we work on indirectly when we work on
transitions before the freeze.
* We do *NOT* remove packages where the maintainer is active on the
bug and is in the process of fixing it or at least finding out what
is going on.
IOW, we remove packages we cannot do anything about as Release Team
members. IOW we indeed remove packages that are Noise in the RC bugs
counts that we have to deal with. It's not a trick, it's a: we can't do
anything about those, get them out from the way, full stop.
[0] http://bts.turmzimmer.net/details.php?bydist=both&sortby=srcpackages&ignhinted=on&ignclaimed=on&ignnew=on&ignmerged=on&ignnonfree=on&ignbritney=on&ignotherfixed=on&new=20&refresh=1800
[1] Note that if such a team has a real existence (like known people
that we can possibly talk to) I wouldn't mind at all to pre-share
what I intend to remove with them before I actually do it so that
they can veto some removals because they will fix it *RSN* (I mean
vetoing a removal "just because it sucks" is out of the question).
At the time of the writing, such a team/person doesn't exist.
Also, I'm here to remove packages, I'm also here to make a package
that was removed enter testing again quicker if needed (as 'new'
package in testing do not respect urgency settings, but release
team members have the power to change that). Package maintainers
that have had their package removed can contact us about that on
the debian-release@ list (Of course we won't force new upstream
releases in 2 days, but if the fix is a patch against the last
version that was in testing, we can consider it).
[2] it doesn't mean that there aren't any Release Team member that
cares about testing usability. I just say that it's not really our
"mission".
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpSgm7OjUMw8.pgp
Description: PGP signature