Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Luk,
thanks for your comment!
On Thu, 23 Sep 2010, Luk Claes wrote:
> > Raphael's article is now published, and is probably a good basis for
> > discussing CUT on -devel@.
> > Free link: http://lwn.net/SubscriberLink/406301/bd522adc828b3461/
>
> Personally I have the feeling that if we would choose for rolling as
> described in the article, that testing would actually get replaced by
> rolling and we do not care about extensive architecture support anymore.
> Not sure if we want to take that route. Personally I think we are
The article describes the broad range of possibilities. But I agree that
it would be bad to pick the extreme choice where rolling only
takes into account the mainstream architectures. I think it's safe
to keep that restriction for installation media made available on
snapshots but rolling itself should be consistent with testing in terms of
architecture support.
Given this, it means rolling becomes a superset of testing outside of
freeze, and a replacement for testing during the freeze. I would suggest
to start that way to not disturb the processes in places, but in the long
term I agree it should supersede testing. testing would be a branch of
rolling that starts at freeze time. This branch could then remove the
packages that are not deemed safe for a long term release.
> already taking the necessary steps to have a nice compromise regarding
> architecture support as well as most removals. Certainly there are
> improvements possible, though I'd rather have them implemented in
> testing proper (even if we would rename testing ;-)).
I would like this if it were possible. But I'm not sure how to achieve it.
How can we ensure that testing always contains a stable version of
chromium ? The current decision of keeping it out of testing was right
given our actual constraints on what's ok for a stable release.
I would argue that we need to redefine our criteria for a stable release
and I plan to have this discussion at some point but I think in the mean
time having rolling is good way to fix this.
How can we ensure that testing continues to be updated during
freeze time ? This one is really not fixable without a second
distribution. I know it's also the most problematic aspect for the release
team because you fear that it will make people care less about getting a
stable release out of the door. I think this fear is not completely
justified, people that do not care do not need an excuse to not care, they
already do it (unfortunately).
> Regarding the snapshots, I think that unless they are not frequent (aka
> one about every 6 months) we'd better spend our energy on more frequent
> d-i releases and just promote the use of testing more. If the snapshots
> would not be frequent they could probably help the general release
> process, be a better service to many users and maybe even help to solve
> the problems we have with clamav and chromium related packages.
Why would non-frequent snapshots help more than frequent snapshots?
Why do you believe that those snapshots would not be d-i releases in some
ways?
Personally I would like to have snapshots every 2 or 3 months. Colin
Watson pointed out in an LWN comment (http://lwn.net/Articles/406597/):
| There's a good chance that CUT could serve a dual purpose of making it
| easier to prepare new stable releases. As many projects have found, if you
| have more-or-less releaseable checkpoints every so often then it's easier
| to prepare a better-than-usual one for your gold release.
And I agree with him in general. By officially endorsing a constantly
usable rolling distribution, it's clear to everybody that what goes in
unstable should always be in a releasable state. And if the regular CUT
snapshot provide motivations to the d-i team to produce a release because
it will be immediately used, it's a benefit for the whole stable release
process. I'm sure some people will call this a pipe dream, but at the very
least, this whole project supports that ideal and we really do not want to
make it more difficult to get a stable release out. We just want to offer
something else for other kind of users that we're currently not serving
as well as we could.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: