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 -de...@. > > 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) -- 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/20100923123030.gc31...@rivendell.home.ouaza.com
