* Stefano Zacchiroli [2011-05-01 15:43 +0200]:
> 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.
Testing also has just little protection against severe breakage if it is
frozen and updates need to go through rarely used suites. An example
illustrates this quite well:
When Lenny was frozen, a new upstream version of libpam-mount uploaded
to sid. A fix for a release critical bug in libpam-mount/testing could
thus not migrate through unstable and the maintainer uploaded it
together with a security related fix to testing-security. The new
package introduced a new bug, it segfaulted when logging in.
This bug was not reported in the four days the package was in
testing-security. After migration to testing, four according bugs were
filed, two of them even within ten hours.
I've put related dates, message-id's and bug numbers at the end of this
mail[1].
> Testing, OTOH, is really unique in that respect, with its mixture of
> fresh software and quarantine period.
A 'frozen' requiring most updates to go through *-proposed-updates would
make this quarantine period a lot less useful, and it would make
circumstances like the one described above a lot more probable.
One cause that testing-proposed-updates is not more widely used is that
there is no good non-altruistic reason for a user to do so. More
up-to-date packages are available in unstable and more tested packages
are available in testing. Partly giving up the protection of the
quarantine period just to get some packages a few days earlier seems to
be a bad deal.
> 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.
To avoid harming the stable release process, packages should to be
tested by many users before they enter testing. The most used suite
containing packages newer than testing is unstable. I think the
migration of unstable to testing should stay as it is now, whether or
not testing is frozen.
If we want to add a new never-freezing suite 'rolling' targeted at final
users, we should find a way to test packages in a sufficing way before
they enter rolling. These packages would be newer than those in rolling
or unstable, but adding a full suite above both does not seem to be
reasonable.
An non-selfcontained suite (like *-updates and experimental) between
unstable and experimental could solve this. Unlike t-p-u, there would
be a reason for users to opt-in to use this suite, since it would
contains the latest non-experimental packages. The need to explicitly
opt-in would help to ensure that pure unstable is sufficiently tested.
Such a suite should be pinned to 500 by default to encourage using all
packages from it rather than just picking specific packages, it should
also only contain packages that would be uploaded to unstable if testing
would not be frozen (both in contrast to experimental). After release,
packages in it could migrate to unstable, either all at once or using
a clever algorithm.
In the following table, I only choose 'sid-updates' as name because it
is short:
---------------------------------------------------------------------
| not frozen | frozen
---------------------------------------------------------------------
| sid | sid
suites: | rolling | rolling
| testing (equal to rolling) | testing (frozen)
| stable | stable
---------------------------------------------------------------------
| sid => testing/rolling | sid => testing
migration: | no migration from sid-updates | sid-updates => rolling
| t-p-u/r-p-u => testing/rolling | t-p-u => testing
| | r-p-u => rolling
---------------------------------------------------------------------
In comparision to Raphael's proposal, the above would weaken the
stability of rolling during the freeze a bit, but it would strengthen
testing's stability. Maintainers would only need to support an
additional release if they upload packages not targeted at the next
release and thus deliberately choose to do so.
Regards
Carsten
[1] Upload:
Mon, 24 Nov 2008 23:32:10 +0000 <e1l4kuy-0000rj...@ries.debian.org>
Migration:
Fri, 28 Nov 2008 16:39:17 +0000 <e1l66nb-0000jo...@ries.debian.org>
Bug reports:
Sat, 29 Nov 2008 00:58:05 +0100 #507194
Sat, 29 Nov 2008 01:37:40 +0100 #507199
Sat, 29 Nov 2008 15:08:51 +0100 #507257
Tue, 2 Dec 2008 21:21:43 +0100 #507592
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110501204318.ga32...@furrball.stateful.de
