On Sun, May 01, 2011 at 02:06:19AM +0200, Pierre Habouzit wrote:
> I think that we should not do any trade off on the quality of
> rolling/testing/the-antechamber-of-stable, but instead raise the quality
> of unstable so that (which isn't *that* bad, unstable is rarely badly
> broken, and I know lots of "stable" releases of linux distributions that
> are in worse state than the average of unstable on the same set of
> packages…):
YMMV, but I don't think the problem in using unstable directly is of
average quality, but rather the fact that you've little shields against
temporary yet severe breakages. apt-listbugs helps a bit, but it depends
too much on the interleaving of upgrades and you might very well be the
first one encountering a big trouble even if you're using apt-listbugs
(I speak out of my own experience here as I use an unstable laptop as my
main productivity environment).
Testing, OTOH, is really unique in that respect, with its mixture of
fresh software and quarantine period. That is the case even if it has
been designed with a different goal in mind. Out of all this
discussion, the challenge that interests me is whether testing (or
something new, similar to it) can be targeted at final users without
having significant differences in its lifetime depending on the release
cycle of Debian stable. As many posts have shown, the difficulty lies in
how (and if) we can do that without harming the stable release process
itself. It might very well be that the 'frozen' proposal does not cut
the deal, but that's not a reason by itself to give up this challenge.
> I've already written one too long mail about that, but allowing DDs to
> spin off some repositories in a PPA-way can be the way. Managing a
> Debian mirror plus all the {uploading,building,bts}-infrastructure is a
> PITA, but if we make it easy, it'll get used.
Amen (see my post with 'PPA' in its subject).
> For now we're not even in the packing CVS era since branching is a
> PITA. Let's make it easy, and then the whole rolling thing will be
> moot because unstable will be good enough for our users 98% of the
> time.
As we have discussed on #d-devel, there might be plenty of lower hanging
fruits than a user-targeted testing out there, but for me there is no
reason not to discuss other topics as well.
> [ And also relaxing our NMU policies would help too but that's yet
> another story: in a few words, we should allow NMUs as soon as there
> is enough acked-by for them… to enforce a minimal level of
> peer-review, so that quality is checked, and relax all the
> conditions to perform NMUs at once ]
I'll repeat this to death: NMU policies are already quite relaxed.
Basically, if you do things properly, there is no bug you cannot fix
with a long DELAYED NMUs. We don't need any change in policy to use NMU
more liberally, we need a culture shift, which IMHO is even happening,
although quite slowly.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature