Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi, On Sun, 26 Sep 2010, Luk Claes wrote: I think that having an official rolling release always available would reduce the pressure of maintainers to always push the latest into the next stable release precisely because there's an alternative... so it would rather help concerning this point. We do already have experimental. experimental is not for the user lambda, and as a maintainer I'm not so happy to have to point users to experimental if they want the latest release. Fixing remaining issues is a general QA problem. We must do more prevention so that unmaintained packages are not discovered only during freeze when it's too late but way sooner. Indeed, so I'm not arguing against having more testing of testing with snapshots. snapshots would be less useful than rolling since they would be outdated compared to testing... more testing is good and you get more testing with more users, it doesn't matter whether they use snapshots, rolling or testing itself. Again it's unrelated to the existence of rolling, the problem is inactive maintainer not taking care of their packages and those are not the same that would actively push their packages to rolling. What do you base this on? It does not at all seem clear to me that rolling would not introduce maintainers who only care about rolling. Nobody can predict the future... but my take is that the people who only care about rolling would be the people who do not care of testing right now already. Those who care about testing would continue to do it. Those maintainers have package that have not migrated to testing for a long time usually. Right, though inactive maintainers are not usually the problem as they can be worked around (NMU). I beg to disagree. All maintainers can be NMUed... so with you argument there's no problem at all. But the truth is that we don't have enough skilled people to NMU and fix all the current problems. If more maintainers were doing their job as they should, we would have less stuff to NMU and we could release sooner. This fear is unjustified. The consequences are much more complicated than this. It might attract more contributors from derivatives which would benefic for the general quality and thus the freeze time. Or it might mean more users who discover the RC bugs quicker than we're doing right now with testing... etc. It might also attract more users that file bugs that are already fixed or that were never in unstable nor testing. Huh? I still fail to see why the problems with testing have to be worked around at instead of be fixed properly. A proper fix takes time. I want the proper fix but I also want to start step by step in the not too distant future. And I want to fix the name: s/testing/rolling/. I can understand your fear but I think it's wrong to be opposed to the rolling idea on the sole ground that it might meant less people caring about a stable release. It's not only that, but also the fear that the problems we do have with testing will stay instead of getting fixed properly... How can I dissolve that fear? I want to start with rolling and I'm fully aware that the proposal doesn't lead to the best workflow compared to something that we would have designed from scratch. But we have an history, squeeze to release and we can't do a big bang. Besides almost none of the changes in Debian have happened that way. I fully want to fix the workflow issue later on with cooperation of all involved parties and I will make proposals. A big part of CUT is also changing our communication, both internal and external: - internal to say to all contributors that testing/rolling is meant to be always usable so you must be careful in everything you upload to sid, no matter whether we're far from release or not and RC bugs are always important to fix, and you must care about migration to testing/rolling because many users will want the latest version in that distribution - external to say to users that testing/rolling can be safely used and is supported by the Debian project at large Of course, we must design rolling in a way that it supports testing and vice-versa. In the mid-long term, they might merge again but right now it's easier to start with a new release where we can experiment a bit rather than push important changes to the current release process. Are you talking about introducing rolling during the current freeze? I think that would only prove my point that it shifts attention away from testing... Besides we still need to fix the current issue we have with chromium and similar packages before the release... I don't know when rolling would be introduced, and I don't know when squeeze will be released. If we start rolling during this freeze, we will probably only do testing + hand-picked updates to make it more usable (i.e. no automatic britney run from unstable to rolling). My attention does not shift: I take care of my own
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On Sun, Sep 26, 2010 at 05:17:36PM +0200, Luk Claes wrote:
I'm not against having a constant useable testing, on the contrary. I
just don't see why we want to choose for working around the problems we
currently have with testing instead of fixing them for everyone.
You seem to be basing your arguments on the implicit assumption that the
target of testing and CUT is the same, whether it's not necessarily the
case. Testing is great for what it offers to Debian now, but some of its
goals conflicts with it being constantly usable, such as the need to
kick out packages which are not suitable for inclusion in a stable
release which will undergo long support. This is not surprising, as that
was not an explicit goal of testing.
You also seem to have another assumption that something like CUT will
reduce the user base of testing which is not to be taken for granted
either. We can discuss this aspect for years, but the only way to find
it out whether it's the case or not it's to actually *try* doing that
and see what's the user reaction (e.g. by monitoring mirror and/or
popcon data). In the past few weeks I've been attending FOSS events, and
my impression is that users have a lot of interest around Debian-based
rolling distributions, be them aptosid, mint, ... or CUT!
All in all, this seems to be one of those classic discussions in which
there are people trying to dissuade other to volunteer work in specific
project area. That's surely not done on purpose, but that's the
impression this thread might give. The real question, IMHO, is how much
the volunteer work that people interested in CUT are ready to contribute
will impact other project areas (question which has been raised also
during the DebConf10 BoF—an event I recommend to watch to get an idea of
the interest around CUT also *inside* the project). My understanding is
that the impact will be very low, so I still see no reasons not to try.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{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. Caposella ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
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
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Luk, On 26/09/10 at 15:55 +0200, Luk Claes wrote: I think this is completely the wrong question, we'd better ask the question: Why do freezes have to take that long? I would be interested in hearing your answer to that question. It would help to understand the rest of your mail. It seems to me that given our quality objectives and the fact that Debian is mostly developed by volunteer developers, it's difficult to do much better than we currently do regarding duration of freezes. 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). To me, it looks like almost everybody in Debian is causing long freezes, not a specific subset of the DDs. But you seem to disagree? I do think having snapshots could help with that goal. I don't see how. Could you elaborate? (Just to clarify, because my mail could be understood differently: I'm honestly very much interested in hearing your RM's opinion on this topic) - Lucas -- 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/20100926144018.ga28...@xanadu.blop.info
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hey, On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes l...@debian.org wrote: IMHO, what is missing from rolling should be added to testing, not worked around by introducing another suite: I believe it's the other way around, actually. To me, adding stuff to testing is the workaround. Testing is not meant to be used like a rolling release distribution, as it is based on a set of constraints which do not have anything to do with rolling releases and constantly reasonably up-to-date distributions. And that's why it rears its ugly head (generally by freeze time) for users which were expecting it to be a rolling-like distribution. 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. And how can that be done? Chromium can't go into stable, so it must be removed from testing as the product of testing is stable. People have suggested backports and volatile, but I see those solutions as an afterthought. 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. I agree that having much shorter freezes would make the situation a lot better and I do believe that snapshots could provide some sort of quality assurance that would help shorten freezes. This does not solve the other issues with using testing the way many people use it nowadays. 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... I think it kind of depends on how the CUT team plans to assure some level of quality to the snapshots. If it's just about automated testing and minimal user intervention (as hinted in the BoF video), I don't see why non-frequent snapshots would be a requirement. 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? Testing or unstable only exist to support stable. Stable is the final product, testing and unstable are byproducts which people aren't supposed to use unless they're trying to improve the next stable in some way. I think what the CUT team is trying to achieve is to make testing or the rolling suite a first-class citizen and I really like that idea. I'm under the impression that some (most?) developers care at least as much about testing and unstable as they care about stable, as they use testing or unstable on a daily basis in their machines. Some may be afraid that a rolling release model would mean some maintainers aren't going to care about stable anymore. I think this is a valid point, but preventing maintainers from working on what they care about doesn't seem right and might actually stray maintainers away from the project. Who knows, maybe having a rolling suite would even allow us to unfork some Debian derivatives. Regards, -- 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/aanlktik81b7l5l8bbivub=5sopzw8-fcm3zhxlygw...@mail.gmail.com
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/26/2010 04:40 PM, Lucas Nussbaum wrote: Hi Luk, Hi Lucas Note that this is my personal opinion and does not represent the opinion of the Release Team perse. On 26/09/10 at 15:55 +0200, Luk Claes wrote: I think this is completely the wrong question, we'd better ask the question: Why do freezes have to take that long? I would be interested in hearing your answer to that question. It would help to understand the rest of your mail. It seems to me that given our quality objectives and the fact that Debian is mostly developed by volunteer developers, it's difficult to do much better than we currently do regarding duration of freezes. Of course there are multiple reasons. Though I think one of the most obvious ones is that we as a project don't do a genuine stable release often so sometimes delay the freeze willingly or not. Another reason IMHO is that instead of working together and sharing the responsability for a release we often tend to do the opposite: by not having clear and timely communication on one hand and by trying to get the latest and greatest last minute at the other hand. I think we as Release Team should work on having better communication with the project on timings of freezes and on why and how some decisions are made. I also think we should evolve to having more responsability to packaging teams and maintainers to choose the versions they want to help support for a longer time. On the other hand I hope packagers could refrain from trying to have last minute changes and help on fixing the remaining issues faster. 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). To me, it looks like almost everybody in Debian is causing long freezes, not a specific subset of the DDs. But you seem to disagree? No, I surely cannot disagree atm. Though I do not want to promote another suite which in effect shifts the attention even more from the testing suite. I do think having snapshots could help with that goal. I don't see how. Could you elaborate? snapshots can be mini releases so they could help in having everyone more familiar with releases and could hopefully help in making communication, coordination and cooperation on releases easier. 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/4c9f612c.4080...@debian.org
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/26/2010 05:02 PM, Fernando Lemos wrote: On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes l...@debian.org wrote: 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... I think it kind of depends on how the CUT team plans to assure some level of quality to the snapshots. If it's just about automated testing and minimal user intervention (as hinted in the BoF video), I don't see why non-frequent snapshots would be a requirement. Right, though I'd rather see them as a kind of mini releases instead. 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? Testing or unstable only exist to support stable. Stable is the final product, testing and unstable are byproducts which people aren't supposed to use unless they're trying to improve the next stable in some way. I think what the CUT team is trying to achieve is to make testing or the rolling suite a first-class citizen and I really like that idea. Right, though I'd rather have testing usable all the time than having an extra suite which will cause an extra burden on maintainers while not helping to have smoother releases. So I'd rather have the best of both than both under expectations. I'm under the impression that some (most?) developers care at least as much about testing and unstable as they care about stable, as they use testing or unstable on a daily basis in their machines. Some may be afraid that a rolling release model would mean some maintainers aren't going to care about stable anymore. I think this is a valid point, but preventing maintainers from working on what they care about doesn't seem right and might actually stray maintainers away from the project. I'm not against having a constant useable testing, on the contrary. I just don't see why we want to choose for working around the problems we currently have with testing instead of fixing them for everyone. 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/4c9f6410.6070...@debian.org
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Luk, thanks for your valuable comments. On Sun, 26 Sep 2010, Luk Claes wrote: Of course there are multiple reasons. Though I think one of the most obvious ones is that we as a project don't do a genuine stable release often so sometimes delay the freeze willingly or not. Another reason IMHO is that instead of working together and sharing the responsability for a release we often tend to do the opposite: by not having clear and timely communication on one hand and by trying to get the latest and greatest last minute at the other hand. I think that having an official rolling release always available would reduce the pressure of maintainers to always push the latest into the next stable release precisely because there's an alternative... so it would rather help concerning this point. We can surely do better in terms of length of freeze and better communication is surely important in the whole picture. Not having rolling does not seem something that will help. I can understand the fear but IMO it's not based on anything concrete. I think we as Release Team should work on having better communication with the project on timings of freezes and on why and how some decisions are made. I also think we should evolve to having more responsability to packaging teams and maintainers to choose the versions they want to help support for a longer time. Full ack. On the other hand I hope packagers could refrain from trying to have last minute changes and help on fixing the remaining issues faster. Fixing remaining issues is a general QA problem. We must do more prevention so that unmaintained packages are not discovered only during freeze when it's too late but way sooner. Again it's unrelated to the existence of rolling, the problem is inactive maintainer not taking care of their packages and those are not the same that would actively push their packages to rolling. Those maintainers have package that have not migrated to testing for a long time usually. No, I surely cannot disagree atm. Though I do not want to promote another suite which in effect shifts the attention even more from the testing suite. This fear is unjustified. The consequences are much more complicated than this. It might attract more contributors from derivatives which would benefic for the general quality and thus the freeze time. Or it might mean more users who discover the RC bugs quicker than we're doing right now with testing... etc. I can understand your fear but I think it's wrong to be opposed to the rolling idea on the sole ground that it might meant less people caring about a stable release. Of course, we must design rolling in a way that it supports testing and vice-versa. In the mid-long term, they might merge again but right now it's easier to start with a new release where we can experiment a bit rather than push important changes to the current release process. 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/20100926184008.gi22...@rivendell.home.ouaza.com
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hi Raphael On 09/26/2010 08:40 PM, Raphael Hertzog wrote: On Sun, 26 Sep 2010, Luk Claes wrote: Of course there are multiple reasons. Though I think one of the most obvious ones is that we as a project don't do a genuine stable release often so sometimes delay the freeze willingly or not. Another reason IMHO is that instead of working together and sharing the responsability for a release we often tend to do the opposite: by not having clear and timely communication on one hand and by trying to get the latest and greatest last minute at the other hand. I think that having an official rolling release always available would reduce the pressure of maintainers to always push the latest into the next stable release precisely because there's an alternative... so it would rather help concerning this point. We do already have experimental. On the other hand I hope packagers could refrain from trying to have last minute changes and help on fixing the remaining issues faster. Fixing remaining issues is a general QA problem. We must do more prevention so that unmaintained packages are not discovered only during freeze when it's too late but way sooner. Indeed, so I'm not arguing against having more testing of testing with snapshots. Again it's unrelated to the existence of rolling, the problem is inactive maintainer not taking care of their packages and those are not the same that would actively push their packages to rolling. What do you base this on? It does not at all seem clear to me that rolling would not introduce maintainers who only care about rolling. Those maintainers have package that have not migrated to testing for a long time usually. Right, though inactive maintainers are not usually the problem as they can be worked around (NMU). No, I surely cannot disagree atm. Though I do not want to promote another suite which in effect shifts the attention even more from the testing suite. This fear is unjustified. The consequences are much more complicated than this. It might attract more contributors from derivatives which would benefic for the general quality and thus the freeze time. Or it might mean more users who discover the RC bugs quicker than we're doing right now with testing... etc. It might also attract more users that file bugs that are already fixed or that were never in unstable nor testing. I still fail to see why the problems with testing have to be worked around at instead of be fixed properly. I can understand your fear but I think it's wrong to be opposed to the rolling idea on the sole ground that it might meant less people caring about a stable release. It's not only that, but also the fear that the problems we do have with testing will stay instead of getting fixed properly... I think it's great to have discussion about the issues and even about possible solutions, though I don't think we should try to be hasty nor introduce extra suites to work around issues we are having with suites we have today. Of course, we must design rolling in a way that it supports testing and vice-versa. In the mid-long term, they might merge again but right now it's easier to start with a new release where we can experiment a bit rather than push important changes to the current release process. Are you talking about introducing rolling during the current freeze? I think that would only prove my point that it shifts attention away from testing... Besides we still need to fix the current issue we have with chromium and similar packages before the release... 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/4c9fb29b.2070...@debian.org
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/23/2010 09:00 AM, Lucas Nussbaum 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/ It's still looks weired to me to have to read this article there (I mean, _only_ there). Can't it just be on CUT's website, or on the wiki? -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- 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/4c9b1280.3040...@dogguy.org
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 23/09/10 at 10:40 +0200, Mehdi Dogguy wrote: On 09/23/2010 09:00 AM, Lucas Nussbaum 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/ It's still looks weired to me to have to read this article there (I mean, _only_ there). Can't it just be on CUT's website, or on the wiki? I agree that it's weird and suboptimal. I would have prefered to have it mailed to -devel@, so we could reply and quote it easily. But there are probably copyright transfer issues. - Lucas -- 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/20100923090607.ga30...@xanadu.blop.info
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On Thu, 23 Sep 2010, Mehdi Dogguy wrote: On 09/23/2010 09:00 AM, Lucas Nussbaum 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/ It's still looks weired to me to have to read this article there (I mean, _only_ there). Can't it just be on CUT's website, or on the wiki? Once the article is freely available on LWN (and not for subscribers only), I can do whatever I want with the article. At that time, people should be free to put it on the wiki. I would like to thank LWN.net for allowing us to publish at least a free subscriber link on this list so that interested people not subscribed at LWN can read it and participate in the discussions. Feel free to copy/paste extracts as well if you want to comment on a specific part. 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/20100923091547.ga28...@rivendell.home.ouaza.com
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On 09/23/2010 09:00 AM, Lucas Nussbaum wrote: On 22/09/10 at 15:01 +0200, Raphael Hertzog wrote: Hi all, On Tue, 21 Sep 2010, Yaroslav Halchenko wrote: CUT discussions at debconf10 and recent news of the birth of Linux Mint discussions on CUT have continued after debconf on the CUT mailing. I wrote a summary of the discussion that will be published in Linux Weekly News before tomorrow. Hopefully this summary will then lead to a constructive discussion on the way forward. Hi, 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 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 ;-)). 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. 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/4c9b353c.8070...@debian.org
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 -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
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
On Thu, 23 Sep 2010 14:30:30 +0200, Raphael Hertzog wrote: 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. There are of course a couple large downsides to this. It becomes next to impossible to make big/interesting changes across the distribution, and developers will be forced (due to the short time frame) into being very conservative with their uploads. Today, maintainers have the important freedom to make big changes at the beginning of the release cycle knowing that they have over a year to fix any resulting problems, and I think it would be a shame to take that away. I view testing snapshots more as a preview for a very limited subset of users; the type that are looking for rather fresh software and would be perfect candidates for testing, but they aren't willing to deal with the daily upgrade treadmill. Again, I think this is a rather small group of users. Mosts users that fall into the I need the latest shiny category are served fairly well by the existing testing. They just need a constantly working installer. Best wishes, Mike -- 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/20100923135023.b45d5e7e.michael.s.gilb...@gmail.com
