Hi Raphael On 09/23/2010 02:30 PM, Raphael Hertzog wrote: > 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.
IMHO, what is missing from rolling should be added to testing, not worked around by introducing another suite: >> 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. I'd rather fix this so chromium can be added to testing and stable. > 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). I think this is completely the wrong question, we'd better ask the question: Why do freezes have to take that long? I do think it's completely wrong to have the people causing the long freezes benefit from another suite which fits better with not really caring about stable, I'd rather have some peer pressure to have a constantly usable testing which can be released fast (aka without a long freeze being necessary). I do think having snapshots could help with that goal. >> 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? Because in that case they could really be used and supported for installing, better user testing, security... > Why do you believe that those snapshots would not be d-i releases in some > ways? Because now it's really hard to have frequent d-i releases aka having two during a current release cycle is about the norm. It's also not that easy to get a d-i release as it needs quite some coordination regarding transitions (which affect d-i) and d-i package uploads. Going from 2 to 8 or more looks impossible to me, while having about 4 should be doable and not cause too much coordination problems. > 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. s/2 or 3 months/6 months/ and I'm with you on this. > 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. Right, though I don't see the need for rolling in this situation unless we want to keep long freezes and half baked solutions for difficult to support packages. I'd rather have these issues fixed than worked around... and I hope many people support that? Cheers Luk -- 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/4c9f50dd.2030...@debian.org
