On Tue, Jun 03, 2008 at 04:18:46PM +0000, Joey Hess wrote:
> Pierre Habouzit wrote:
> > 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.
>
> If testing is not intended to be a usable distribution, then the d-i
> team should stop trying to make releases using it. d-i needs a usable
> distribution to install, or we don't get any, well, testing.
>
> This will, as you perhaps know, require 2 to 6 months of development
> work after testing *does* become a usable distribution (ie, post-freeze)
> before a d-i can be released for it.
It depends of your definition of usable. I don't think it's usable on
a daily basis because:
* it doesn't get a lot of security updates (those must migrate first,
and it's not often possible, though testing-security partly
addresses that, I don't know how well it's up2date) ;
* on a regular basis some packages are broken because it depends on an
RC to be fixed and to migrate (variant of the previous one for RC
bugs) ;
* on a regular basis some packages are removed and must migrate again,
and that's good because it's better not to have a package than a
completely broken one. Brokeness is unstable.
It not "unusable" in the sense that you can't use it, just that you
won't have the experience that a full stable has, nor the one you seek
in unstable usually.
> My experience in and with the release team has been that team members
> are very interested in keeping testing as usable as possible, and spend
> a lot of time on this, including getting down in the trenches and fixing
> bugs.
I also do. Though we (release team member) cannot NMU every single RC
bug out there, we don't scale. I usually concentrate my work on central
packages, which leaves packages usually are not.
> Sometimes they have to make a hard decision such as dropping a RC
> buggy package from testing, but this decision is hard precicely
> because they know that it can hurt the usability, desirability, and
> releasability of testing.
Yes, we agree here, maybe "unusable" was a bit strong, but I think I
explained what I meant earlier more precisely.
> It sounds like this has become an easy decision for you; that's very
> worrying.
It's an easy decisions because I believe my standards for removal to
be high[0]. And because I'm very available to help a maintainer/DD
bringing a package back into testing when someone gets a patch for a RC
that warranted its removal earlier. I'm not worried because those
removal are easy to undo when a fixed package is here.
Of course, when the freeze will come, this will change (easiness to
get back), and then the reasons for removal will be tighter.
I'd like to state another thing that people miss. Packages that are
removed often have other RC bugs. And a package with more RC bugs in
unstable than in testing doesn't migrate. Leaves packages are more
likely to have huge depends chains, and to get in the way of transitions
than others. Less RC buggy packages in testing means easier transitions,
means easier release management, means in turn less frustration.
And again (yeah I feel like I repeat myself on this) I would be more
than glad to work closely with people from QA or any group that would
prevent packages to be removed. I've offered to sponsor NMUs for QA
people that aren't DDs many time in the past, and I still do. I don't
really know what I could do more to help _not_ removing packages, except
NMUing the bugs myself -- but NMUing the bugs myself just doesn't scale,
it's micromanagement[1].
[0] For example I don't remove a package when there is recent activity
on a bug report from the maintainer, or from a DD that stated his
intention to NMU if needed. It's not removal for the sake of it,
it's removal because we have a damn broken package in testing
no-one seems to care about.
[1] I do NMU packages I care about as a user, but it's not RM work,
it's QA work, and it's not something that need any
super-release-team-cow-powers to do. That's why I repeat it's not
a Release Team mission. It's a QA team mission, and *EVERYONE OF
US* is entitled to do that job.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpKDEAx4x3EY.pgp
Description: PGP signature