Re: A new Priority level, ???backports??? ? (Re: unstable/testing/[pending/frozen/]stable)
On Fri, Oct 08, 2010 at 10:58:24AM +0900, Charles Plessy wrote: I was acually meditating on Joerg's answer for the past two weeks, wondering that if my some of my packages are bullshit, I should look for another place to distribute them instead of letting them be a burden for everybody. I did not read any answer in the sense that some packages are a burden. IMHO only those packages are a burden which are hanging around ages with RC bugs or low popcon packages who are not maintained actively (and thus might contain RC bugs but nobody notices). None of the packages I maintain can be described as being a integral part of an ???operating system???. None of them is essential to Debian. We have a category essential but I do not think that this category maps to what you mean with essential. It is hard to define what building blocks are essentially for building an universal operating system and thus we will probably run circles in deciding whether a package is essential / needed / nice to have / whatever. IMHO, the most important thing is that a package is properly maintained. Would a Debian PPA or a private repository be a better place for them? Personally, I do not think so. I don't think so neither. In the sense of my paragraph above you can not find a clear borderline what belongs to Debian and what not. I have embraced the ???Debian Pure Blend??? concept, which is to do our work in Debian, not as a supplement to Debian. IMHO (for sure ;-)) this is a reasonable concept. Now that Debian has an official backports suite, I think that it can change the way we distribute our final products: packages that have demonstrated their quality by migrating and staying in Testing. I do not really see in how far the existence of the official backports suite should change the look onto Debian stable in general. I have understood backports as an additional service to the existing stable and not as a reason to drop packages from stable. This whole thing does not make sense at all. Priority is the wrong knob. [???] !!! The package priorities establish concentric subnetworks of our binary dependancy graph. Yes. I think that it is an interesting property that is under-used. I do not think so. Having a priority lower than extra would allow packages to coexist in Testing without interfering with Stable. They would have the same aims in terms of quality ??? that is the responsibility of the maintainer. But why? I do not see a reason to have packages inside Debian which do not deserve to end up in stable. Debian stable is THE PRODUCT we are releasing, it is the goal we are working towards. There are people relying on this product and I do not see any reason to exclude a set of packages from stable. However, the lower-priority package would not pretend at the same durability, which is two to four years if we take the freeze and the Oldstable support in account. In two years, some packages that are currently in Squeeze will still be fine for most users, while for others, users interest for such an old version can be very low. IMHO this paragraph just proves that the priority scale and the aging of programs scale are orthogonal and priority is just the wrong knob. There are people who are needing the latest postgresql, open(libre?)office, firefox (for whatever reason) but none of these packages would even go into the category extra. On the other end of your arguing we have some scientific software which is not maintained upstream any more, has low popcon but has some use for a certain amount of users anyway and thus is maintained by Debian Med/Science team. From a priority point of view they could qualify for below extra. However, these packages are completely wrong in backports because they are just not updated by upstream any more. So priority and actuality of a package are just different dimensions. For this, the maintainer sometimes can do little, apart from giving up packaging software from young projects. Why? Having an old version in stable and having a more up to date version in backports is the solution, isn't it? Although it is not a problem to release these packages in Stable, I think that ??? in the case of some packages I maintain in the Debian Med team ??? we would send a clearer message by distributing them to our Stable users only as backports. Without compromising on the quality. If I would try to wear my users hat I would definitely not understand your message. It's rather confusing than clear from my point of view. Kind regards Andreas. -- http://fam-tille.de -- 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/20101008072452.gb19...@an3as.eu
Re: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)
Hi all, I was acually meditating on Joerg's answer for the past two weeks, wondering that if my some of my packages are bullshit, I should look for another place to distribute them instead of letting them be a burden for everybody. Since he sent his anwer again, I will reply again. Let's hope it dissipates misunderstandings. None of the packages I maintain can be described as being a integral part of an ‘operating system’. None of them is essential to Debian. Would a Debian PPA or a private repository be a better place for them? Personally, I do not think so. I have embraced the ‘Debian Pure Blend’ concept, which is to do our work in Debian, not as a supplement to Debian. Now that Debian has an official backports suite, I think that it can change the way we distribute our final products: packages that have demonstrated their quality by migrating and staying in Testing. Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit : Le Thu, Sep 23, 2010 at 12:38:16AM +0900, Charles Plessy a écrit : the addition of new suites has the disadvantage of dispersing our userbase. Here is a proposition that conserves the current flow of package migration for packages released in Stable, and that makes Testing the meeting point for all the packages. We could introduce a new priority level, ‘backports’, with the following features: This whole thing does not make sense at all. Priority is the wrong knob. […] So what backports priority actually says is my package is such a bullshit that I don't want it ever released, but I am fine with putting burden on the people keeping backports running instead. I think we have a way already dealing with this: Don't upload them. The package priorities establish concentric subnetworks of our binary dependancy graph. I think that it is an interesting property that is under-used. Having a priority lower than extra would allow packages to coexist in Testing without interfering with Stable. They would have the same aims in terms of quality – that is the responsibility of the maintainer. However, the lower-priority package would not pretend at the same durability, which is two to four years if we take the freeze and the Oldstable support in account. In two years, some packages that are currently in Squeeze will still be fine for most users, while for others, users interest for such an old version can be very low. For this, the maintainer sometimes can do little, apart from giving up packaging software from young projects. Although it is not a problem to release these packages in Stable, I think that — in the case of some packages I maintain in the Debian Med team — we would send a clearer message by distributing them to our Stable users only as backports. Without compromising on the quality. This, more than the particular implementation (based on priorities or not) is what I am proposing. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20101008015824.gb15...@merveille.plessy.net
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
Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
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/ I also had prepared a summary of CUT discussion before Raphael worked on his article, which can also be useful to understand the global picture: http://lists.alioth.debian.org/pipermail/cut-team/2010-August/71.html It would probably need some more work though, so please read it with care (see the follow-up messages, too). - 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/20100923070031.ga24...@xanadu.blop.info
Re: A new Priority level, ‘backports’ ? (Re: unstable/testing/[pending/frozen/]stable)
the addition of new suites has the disadvantage of dispersing our userbase. Here is a proposition that conserves the current flow of package migration for packages released in Stable, and that makes Testing the meeting point for all the packages. We could introduce a new priority level, ‘backports’, with the following features: This whole thing does not make sense at all. Priority is the wrong knob. This priority level would be lower than ‘extra’. Higher levels would not be allowed to depend nor build-depend on packages of priority ‘backports’. Source packages would not be allowed to contain a mixture binary packages containing ‘backports’ level and higher priorities. These packages would not be released in Stable, but would be uploaded to Unstable and migrate in Testing as usual, with the exception that they would not be affected by a freeze. They could be removed by default from Testing in case they block a transition. As the name indicates, the packages which prove their stability in Testing (and only them, as in the current backports rules) would be backported in backports.debian.org. The backports would be prepared by the maintainers themselves (this would open a way to the use of the BTS) and would be the final distribution medium for Stable users. So what backports priority actually says is my package is such a bullshit that I don't want it ever released, but I am fine with putting burden on the people keeping backports running instead. I think we have a way already dealing with this: Don't upload them. -- bye, Joerg 'To Start Press Any Key'. Where's the ANY key? -- 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/87vd5xszdd@gkar.ganneff.de
Re: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)
Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit : So what backports priority actually says is my package is such a bullshit that I don't want it ever released, but I am fine with putting burden on the people keeping backports running instead. I think we have a way already dealing with this: Don't upload them. These packages are not that bad, since the FTP team accepted them… Cheers, -- Charles -- 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/20100923081249.gc14...@merveille.plessy.net
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: A new Priority level, ‘ backports ’ ? (Re: unstable/testing/[pending/frozen/]stable)
On Thu, Sep 23, 2010 at 17:12:49 +0900, Charles Plessy wrote: Le Thu, Sep 23, 2010 at 09:17:02AM +0200, Joerg Jaspert a écrit : So what backports priority actually says is my package is such a bullshit that I don't want it ever released, but I am fine with putting burden on the people keeping backports running instead. I think we have a way already dealing with this: Don't upload them. These packages are not that bad, since the FTP team accepted them… As far as I can tell the FTP team bases its accept/reject decisions on whether it's legal for us to distribute a package (and whether it's suitable for the component it was uploaded to in terms of the dfsg), not whether it's a good idea to put that package in the distribution. Cheers, Julien signature.asc Description: Digital signature
Re: unstable/testing/[pending/frozen/]stable
Hi, On Wed, 22 Sep 2010, Yaroslav Halchenko wrote: hm... did you mean http://lwn.net/Articles/406301/ A constantly usable testing distribution for Debian? Yes. if indeed, taken on the reasoning that testing is a bad name and rolling is better, then it goes similar to what I saw behind 'constatly present' testing up to replacing rolling - testing -[removal of packages] - frozen Well, summarizing the whole with a few arrows is difficult but note that the current rolling proposal is more like this: Outside of freeze: -- unstable → testing → rolling ↑ targetted uploads During freeze: -- t-p-u→ testing ↗ (not automatic) unstable → rolling ↑ targetted uploads now about 'pending': following description confused me quite a bit: ... during a freeze, testing is no longer automatically updated, which makes it inappropriate to feed the rolling distribution. That's why rolling would be reconfigured to grab updates from unstable (but using the same rules as testing). But unstable remains to serve as the entry point to feed frozen testing as well, so with absent other entry-point (pending in my scenario) there is a conflict -- I can't upload 1 version which I intend to get to frozen testing and another one to get into rolling (experimental obviously can't serve as such). or it all would go through an addendum (*-proposed-updates)? That entry point aleady exists and is called testing-proposed-updates indeed. 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/20100923092730.gb28...@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
Re: A new Priority level, ‘backports’ ? (Re: unstable/testing/[pending/frozen/]stable)
Marc Haber mh+debian-de...@zugschlus.de writes: The ftp team has a history of strongly discouraging uploads that they don't feel like accepting (such as a package that would download eicar.com from the internet and place it in a defined place where other packages might find and use it) and of killing of packages on grounds that nobody sane would use them, such as clamav-data, which force-died in the course of volatile moving under the ftp team's reign. I completely support the FTP team's refusal to accept completely automatically generated and automatically signed (unattended) packages in the archive. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87wrqcxcv2@windlord.stanford.edu
Re: unstable/testing/[pending/frozen/]stable
On Tue, 21 Sep 2010 20:52:09 -0400 Yaroslav Halchenko deb...@onerussian.com wrote: Hi All, CUT discussions at debconf10 and recent news of the birth of Linux Mint Debian Edition (LMDE) [1] show how valuable and unique Debian's rolling distribution (testing) is. But every freeze in the preparation to upcoming stable release in effect, eliminates 'testing' (and actually unstable... I don't see what that is meant to mean. Testing and unstable are constantly present and functional during a freeze. What happens is that the pace of new (disruptive) uploads and migrations is manually limited. i.e. the stability and functionality of testing and unstable *rise* during a release freeze simply because new transitions are not started - in unstable or testing. Unstable needs to be managed during a freeze because it is the destination of uploads which fix RC bugs in testing. If there was a new migration/transition in unstable affecting this package, the new upload cannot migrate (and cannot fix the bug). Testing-proposed-updates isn't an excuse for making a mess of unstable during a freeze. since experimental is not a complete distribution and we can't force users to use something with that name ;) ) until new stable sees the world. I wondered, why don't we have [experimental/]unstable(sid)/testing(e.g squeeze)/stable *constantly* present and functioning all the time the same way. So when and where are library transitions meant to occur? Transitions are always disruptive, always cause some packages to be non-functional or non-installable. There has to be somewhere (unstable) where libfoo2 can be uploaded with libfoo2-dev so that all packages which depend on libfoo1 can start the migration to the new API. As the migration starts, there is a period (which in the case of GTK1-2 took several years) where many packages in unstable are uninstallable or FTBFS or just horribly buggy. Then upon freeze we just copy the state of unstable - pending testing(squeeze) - frozen(squeeze, e.g together with a codename) and link new codename (e.g. wheezy) against testing. unstable is not compatible with *-proposed-updates - nor is having *-proposed-updates an excuse for starting new transitions in unstable during a freeze. Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? , and pending-frozen according to the freeze schedule. This would enable CUTs, fulfill the ideas behind LMDE to have something rolling without hickups, and users of 'testing' (and unstable) would enjoy testing/unstable the way they usually do. I understand that it would require more work, but I think benefits would overweight the burden. But I cannot be first thinking about that, and I bet there were good reasons why such approach was not taken -- could anyone enlighten/point me to the shortcomings? In a word, transitions. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp2oooMpquY1.pgp Description: PGP signature
Re: unstable/testing/[pending/frozen/]stable
On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? I think his proposal boils down to this: we *always* have unstable and testing to upload whatever we want and handle transitions when we like. Then, parallel to unstable/testing, there would be the pending/frozen suites to work on the release. Saying it a bit differently, we would *also* already be working on release+1 while release is being frozen. I kind of like the idea. To give an example with package names, I would already upload iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies until they are fixed to use xulrunner 1.9.2, while keeping updates for iceweasel 3.5 in pending/frozen. It would also allow me to push iceweasel 4.0 betas to experimental, where they would be better suited than their current location, where they are not even built on non x86/x86-64. This could be more work, but I understand that for people who want to do it, the testing freeze time is frustrating. Mike PS: for my personal needs, some way to get random packages autobuilt would already be helpful (call that ppa if you want). -- 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/20100922064731.ga16...@glandium.org
Re: unstable/testing/[pending/frozen/]stable
On Wed, 22 Sep 2010 08:47:31 +0200 Mike Hommey m...@glandium.org wrote: On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? I think his proposal boils down to this: we *always* have unstable and testing to upload whatever we want and handle transitions when we like. Then, parallel to unstable/testing, there would be the pending/frozen suites to work on the release. Saying it a bit differently, we would *also* already be working on release+1 while release is being frozen. I kind of like the idea. Splitting the user base / testing base isn't necessarily a good idea. In other words, it might work for heavily utilised packages but it would cause a lot of complexity in bug triage. How is the maintainer meant to test the version in unstable if he's running the frozen version or vice-versa? To give an example with package names, I would already upload iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies until they are fixed to use xulrunner 1.9.2, while keeping updates for iceweasel 3.5 in pending/frozen. It would also allow me to push iceweasel 4.0 betas to experimental, where they would be better suited than their current location, where they are not even built on non x86/x86-64. With something like iceweasel, is there frankly any point in building experimental versions on architectures which can barely handle the stable releases? How many users are there using iceweasel not on x86/x86-64? This could be more work, but I understand that for people who want to do it, the testing freeze time is frustrating. New versions break stuff - there has to be a way of stabilising bleeding-edge code and that should not be in a quiet backwater with no users. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgprWd0xrIva2.pgp Description: PGP signature
Re: unstable/testing/[pending/frozen/]stable
On 09/22/2010 08:47 AM, Mike Hommey wrote: On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? I think his proposal boils down to this: we *always* have unstable and testing to upload whatever we want and handle transitions when we like. Then, parallel to unstable/testing, there would be the pending/frozen suites to work on the release. Saying it a bit differently, we would *also* already be working on release+1 while release is being frozen. I kind of like the idea. To give an example with package names, I would already upload iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies until they are fixed to use xulrunner 1.9.2, while keeping updates for iceweasel 3.5 in pending/frozen. It would also allow me to push iceweasel 4.0 betas to experimental, where they would be better suited than their current location, where they are not even built on non x86/x86-64. It means that the Release Team will have to handle transitions in unstable, migrations to testing, as well as the ongoing freeze in frozen. I don't think we have enough manpower for that. And, during a freeze, we need each one to concentrate on fixing things (while there is still experimental to test things). If we add a play-forever-suite, we will loose some manpower without any doubt and it will make releases harder to acheive, imho. Besides, how de we merge things after a release? unstable would be something quite different from released frozen. Some bugfixes might have been applied only for frozen or pending, some other package will have new versions in unstable (and their rev-deps rebuilt)… I think it could be a nightmare to manage, imho. Regards, -- 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/4c99b1b2.5040...@dogguy.org
Re: unstable/testing/[pending/frozen/]stable
On Wed, 22 Sep 2010 07:31:45 +0100 Neil Williams codeh...@debian.org wrote: So when and where are library transitions meant to occur? Transitions are always disruptive, always cause some packages to be non-functional or non-installable. There has to be somewhere (unstable) where libfoo2 can be uploaded with libfoo2-dev so that all packages which depend on libfoo1 can start the migration to the new API. As the migration starts, there is a period (which in the case of GTK1-2 took several years) where many packages in unstable are uninstallable or FTBFS or just horribly buggy. (note: this only gets worse with libfoo-dev_2 replacing libfoo-dev_1 but that does not mean that libfoo-dev should be disallowed or deprecated.) But I cannot be first thinking about that, and I bet there were good reasons why such approach was not taken -- could anyone enlighten/point me to the shortcomings? In a word, transitions. Personally, I've always considered it *more* important for Debian to stabilise code than to always have the newest code. Stable beats new every time. I run a mix of Debian machines, some for Debian development which run unstable, some for Emdebian development which run testing and some for upstream development which run stable. That is quite enough work, thanks, I really, really don't want to have to add another variant of unstable and/or testing to suit the needs of people who prioritise buggy bleeding edge code over stable tools. The core system (i.e. everything I'm not currently debugging) must be stable and reliable if I'm going to get my work done. Do people really want a version of unstable that always has the latest broken version of iceweasel or some horrible partial transition to python3 or the bleeding edge version of Xorg built directly from VCS and which constantly crashes?? Having *everything* new and bleeding edge means that no bugs ever get identified because you cannot tell which bit is bust or the bug you want to fix is blocked by a bug in the X server or the python interpreter or a buggy version of libgcc1 or something. The platform (whatever packages are deemed part of the platform for any one developer) *must* be stable if the code is to improve. Therefore, individual developers need a stable platform onto which can be added their own buggy code - not as packages from Debian but as checkouts from whichever VCS is in use. Predictability and reliability are key components of a usable development platform. Without those, there is no chance of fixing intermittent or corner case bugs. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpUYK2tSFX6o.pgp Description: PGP signature
Re: unstable/testing/[pending/frozen/]stable
On Wed, Sep 22, 2010 at 08:26:22AM +0100, Neil Williams wrote: On Wed, 22 Sep 2010 08:47:31 +0200 Mike Hommey m...@glandium.org wrote: On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? I think his proposal boils down to this: we *always* have unstable and testing to upload whatever we want and handle transitions when we like. Then, parallel to unstable/testing, there would be the pending/frozen suites to work on the release. Saying it a bit differently, we would *also* already be working on release+1 while release is being frozen. I kind of like the idea. Splitting the user base / testing base isn't necessarily a good idea. In other words, it might work for heavily utilised packages but it would cause a lot of complexity in bug triage. How is the maintainer meant to test the version in unstable if he's running the frozen version or vice-versa? How is the maintainer meant to test the version in stable if he's running the unstable version of vice-versa? and s/stable/testing/. Anyways, yes, it might work for heavily utilised packages, but on the other hand, they are exactly the kind of packages where it would make sense. To give an example with package names, I would already upload iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies until they are fixed to use xulrunner 1.9.2, while keeping updates for iceweasel 3.5 in pending/frozen. It would also allow me to push iceweasel 4.0 betas to experimental, where they would be better suited than their current location, where they are not even built on non x86/x86-64. With something like iceweasel, is there frankly any point in building experimental versions on architectures which can barely handle the stable releases? There frankly is one: that of catching bugs early. For example, I already know iceweasel 4.0 betas are broken on several of our architectures. If I hadn't tried to build it once, I wouldn't have realized until I uploaded 4.0 final, at which point it's even harder to get fixes upstream, which means yet more patches applied to our package. For instance, being able to work on 4.0 since its early days helped getting the number of patches from 100+ on 3.5 and 3.6 down to around 50. How many users are there using iceweasel not on x86/x86-64? Do you realize the iceweasel package is not about iceweasel alone? Check the number of build-rdeps and rdeps on libmozjs, and xulrunner. And who knows what future netbooks may bring more users for mips or arm, for instance? 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/20100922074654.ga19...@glandium.org
Re: unstable/testing/[pending/frozen/]stable
Hi, On Tue, Sep 21, 2010 at 08:52:09PM -0400, Yaroslav Halchenko wrote: NB I am having some deja vu that 'frozen' used to be used explicitly in the archive... is that so? Indeed. That was before testing was introduced. Then unstable/testing would roll further as usual, and pending-frozen according to the freeze schedule. This would enable CUTs, fulfill the ideas behind LMDE to have something rolling without hickups, and users of 'testing' (and unstable) would enjoy testing/unstable the way they usually do. The introduction of testing has had positive and negative effects. While it is generally a good thing that packages are tested for some time and required to be consistent with respect to other packages to even be considered for a release, it has also led to a situation where releases are mostly ignored by some maintainers, who just continue to upload new packages and live with the consequence that some snapshot goes into stable. I'm not sure whether explicitly telling people that it is okay to upload new versions to unstable while a release is being prepared is a good thing in that context. Simon -- 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/20100922080333.ga2...@richter
Re: unstable/testing/[pending/frozen/]stable
On 09/22/2010 02:52 AM, Yaroslav Halchenko wrote: [...] [experimental/]unstable(sid)/testing(e.g squeeze)/stable *constantly* present and functioning all the time the same way. Then upon freeze we just copy the state of unstable - pending testing(squeeze) - frozen(squeeze, e.g together with a codename) and link new codename (e.g. wheezy) against testing. while I like the idea to support distributions like MINT which pull from testing, I doubt it would be useful for Dbeian. Even if we would have the manpower in the release team to handle it, I'd expect that a lot of developers would concentrate on throwing new stuff into unstable instead of fixing bugs to be able to release soon. The proper way to fix the issue is to release faster by fixing all remaining issues faster :) -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4c99bc6b.6020...@bzed.de
Re: unstable/testing/[pending/frozen/]stable
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. http://cut.debian.net/ http://lists.alioth.debian.org/pipermail/cut-team/ [experimental/]unstable(sid)/testing(e.g squeeze)/stable *constantly* present and functioning all the time the same way. You're not alone wishing that. I also would like Debian to provide a rolling distribution that never stops to roll. :-) NB I am having some deja vu that 'frozen' used to be used explicitly in the archive... is that so? Yes. frozen was a snapshot of unstable at time of freeze, and people could upload to frozen directly afterwards to fix remaining RC bugs. But I cannot be first thinking about that, and I bet there were good reasons why such approach was not taken -- could anyone enlighten/point me to the shortcomings? I'm not sure it was an explicit choice at that time. We just had to adjust the way we dealt with freeze once testing was introduced. Getting fixes from unstable is easier/safer for everybody compared to testing-proposed-updates so release managers asked people to not upload packages which could not migrate to testing and many do. It also means unstable is less interesting during freeze. Also having the package in unstable for some time ensures that it doesn't break horribly, something that you don't have with testing-proposed-updates. There is room for improvements here I think. On Wed, 22 Sep 2010, Mehdi Dogguy wrote: It means that the Release Team will have to handle transitions in unstable, migrations to testing, as well as the ongoing freeze in frozen. I don't think we have enough manpower for that. And, during a freeze, we need each one to concentrate on fixing things (while there is still experimental to test things). If we add a play-forever-suite, we will loose some manpower without any doubt and it will make releases harder to acheive, imho. I think that if you concentrate on preparing the next release like you do, volunteers that are not interested in the stable release (except for their own package) will show up and deal with migrations to rolling. It's always the same story, you can't force people to care about stable simply by not having a play-forever-suite. And we do have people working on derivative distributions that rely on testing's constant freshness, maybe some of them would be interested to help as well. Anyway, I'd like to ask you all to hold off the discussion for a few hours until everybody can read the summary of the CUT discussions and have a clearer ideas of the proposals and the implications. 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/20100922130147.gh4...@rivendell.home.ouaza.com
Re: unstable/testing/[pending/frozen/]stable
On 22/09/2010 15:01, Raphael Hertzog wrote: I think that if you concentrate on preparing the next release like you do, volunteers that are not interested in the stable release (except for their own package) will show up and deal with migrations to rolling. It won't happen but I'd be happy to be proven wrong though. It's always the same story, you can't force people to care about stable simply by not having a play-forever-suite. We are not trying to force people, but rather trying to give them a bit of responsibility during the release process. « Releasing is a shared responsibility, not only release team's »… And we do have people working on derivative distributions that rely on testing's constant freshness, maybe some of them would be interested to help as well. Nice plan! Please let me know what it happens. Anyway, I'd like to ask you all to hold off the discussion for a few hours until everybody can read the summary of the CUT discussions and have a clearer ideas of the proposals and the implications. Ack. Cheers, -- 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/4c9a0f00.70...@dogguy.org
Debian ppa (was Re: unstable/testing/[pending/frozen/]stable)
Hi, On Mittwoch, 22. September 2010, Mike Hommey wrote: PS: for my personal needs, some way to get random packages autobuilt would already be helpful (call that ppa if you want). I seem to recall, ftpmaster was planning something like that. Or wanted to? If so, what the status? If not, shall we start it? I think so. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Debian ppa (was Re: unstable/testing/[pending/frozen/]stable)
On Wed, Sep 22, 2010 at 16:24:44 +0200, Holger Levsen wrote: Hi, On Mittwoch, 22. September 2010, Mike Hommey wrote: PS: for my personal needs, some way to get random packages autobuilt would already be helpful (call that ppa if you want). I seem to recall, ftpmaster was planning something like that. Or wanted to? If so, what the status? If not, shall we start it? I think so. HE proposed something like this (on the buildd side) for gsoc, there were no takers, iirc. Cheers, Julien signature.asc Description: Digital signature
A new Priority level, ‘bac kports’ ? (Re: unstable/testing/[pending/frozen/]stable)
Dear Yaroslav and everybody, the addition of new suites has the disadvantage of dispersing our userbase. Here is a proposition that conserves the current flow of package migration for packages released in Stable, and that makes Testing the meeting point for all the packages. We could introduce a new priority level, ‘backports’, with the following features: This priority level would be lower than ‘extra’. Higher levels would not be allowed to depend nor build-depend on packages of priority ‘backports’. Source packages would not be allowed to contain a mixture binary packages containing ‘backports’ level and higher priorities. These packages would not be released in Stable, but would be uploaded to Unstable and migrate in Testing as usual, with the exception that they would not be affected by a freeze. They could be removed by default from Testing in case they block a transition. As the name indicates, the packages which prove their stability in Testing (and only them, as in the current backports rules) would be backported in backports.debian.org. The backports would be prepared by the maintainers themselves (this would open a way to the use of the BTS) and would be the final distribution medium for Stable users. The system I propose is intended to keep fruitful interactions between higher turnover packages and stable releases: - It would keep Unstable and Testing as a central point for our users who would like an early access to new software, therefore preserving a high number of testers for the packages of higher quality, which are aimed at Stable. (In contrary for instance to distribution outside of Debian or in the experimental suite.) - Since immediatly after the release the backports are trivial, it would motivate the interest of the maintainers of ‘Priority: backports’ packages for Stable and its release process, to ensure frequent windows of easy backporting. - By removing from testing – on a voluntary basis – a lot of packages for which there is no stable upstream release, or which are still in active development, it would reduce the load on regular operations. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100922153816.ga28...@merveille.plessy.net
Re: unstable/testing/[pending/frozen/]stable
On September 22, 2010 01:35:14 am Mehdi Dogguy wrote: On 09/22/2010 08:47 AM, Mike Hommey wrote: On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? I think his proposal boils down to this: we *always* have unstable and testing to upload whatever we want and handle transitions when we like. Then, parallel to unstable/testing, there would be the pending/frozen suites to work on the release. Saying it a bit differently, we would *also* already be working on release+1 while release is being frozen. I kind of like the idea. To give an example with package names, I would already upload iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies until they are fixed to use xulrunner 1.9.2, while keeping updates for iceweasel 3.5 in pending/frozen. It would also allow me to push iceweasel 4.0 betas to experimental, where they would be better suited than their current location, where they are not even built on non x86/x86-64. It means that the Release Team will have to handle transitions in unstable, migrations to testing, as well as the ongoing freeze in frozen. I don't think we have enough manpower for that. And, during a freeze, we need each one to concentrate on fixing things (while there is still experimental to test things). If we add a play-forever-suite, we will loose some manpower without any doubt and it will make releases harder to acheive, imho. Besides, how de we merge things after a release? unstable would be something quite different from released frozen. Some bugfixes might have been applied only for frozen or pending, some other package will have new versions in unstable (and their rev-deps rebuilt)… I think it could be a nightmare to manage, imho. Unstable and Testing appear to quickly diverge from a new release's versions, becoming something quite different from released, in a matter of days or few weeks. The only difference in this regard if a frozen existed would be that they could diverge sooner... wouldn't that be a headstart on the next Stable? What if packages only became frozen when the set of dependency relationships they are involved in is consistent (enough?) In this scenario there would be no (only minor?) transitions happening in Frozen, and consequently no (little?) need to merge dependency related bugfixes (the only some of consequence, afaict) into Unstable or Testing packages. Simply having that as a goal may encourage more or more prompt work on packages in Testing. I've heard that Testing cycles between good/installable and bad/un-installable--do those good times correspond to times when it would be possible to freeze a set of packages? i.e., is there already an indicator that can be used to trigger a mostly automatic action which over time would result in Frozen becoming a release candidate? anyways, here's a somewhat philosophical thought on the matter... Currently Debian can only see the past (Stable) and present (Unstable/Testing). Creating an always-consistent-frozen category of packages would let Debian see the past (Stable), present (Frozen), and future (Unstable/Testing). - Bruce -- 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/201009221117.16849.bms...@shaw.ca
Re: unstable/testing/[pending/frozen/]stable
On 2010-09-22, Bruce Sass bms...@shaw.ca wrote: I've heard that Testing cycles between good/installable and bad/un-installable--do those good times correspond to times when it would be possible to freeze a set of packages? You're wrong. That's FUD you've read. Cheers Philipp Kern -- 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/slrni9ko8v.nl.tr...@kelgar.0x539.de
Re: unstable/testing/[pending/frozen/]stable
On Wed, 22 Sep 2010, Raphael Hertzog wrote: Anyway, I'd like to ask you all to hold off the discussion for a few hours until everybody can read the summary of the CUT discussions and have a clearer ideas of the proposals and the implications. hm... did you mean http://lwn.net/Articles/406301/ A constantly usable testing distribution for Debian [LWN subscriber-only content] ? if indeed, taken on the reasoning that testing is a bad name and rolling is better, then it goes similar to what I saw behind 'constatly present' testing up to replacing rolling - testing -[removal of packages] - frozen now about 'pending': following description confused me quite a bit: ... during a freeze, testing is no longer automatically updated, which makes it inappropriate to feed the rolling distribution. That's why rolling would be reconfigured to grab updates from unstable (but using the same rules as testing). But unstable remains to serve as the entry point to feed frozen testing as well, so with absent other entry-point (pending in my scenario) there is a conflict -- I can't upload 1 version which I intend to get to frozen testing and another one to get into rolling (experimental obviously can't serve as such). or it all would go through an addendum (*-proposed-updates)? -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- 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/20100923022237.gw12...@onerussian.com
unstable/testing/[pending/frozen/]stable
Hi All, CUT discussions at debconf10 and recent news of the birth of Linux Mint Debian Edition (LMDE) [1] show how valuable and unique Debian's rolling distribution (testing) is. But every freeze in the preparation to upcoming stable release in effect, eliminates 'testing' (and actually unstable... since experimental is not a complete distribution and we can't force users to use something with that name ;) ) until new stable sees the world. I wondered, why don't we have [experimental/]unstable(sid)/testing(e.g squeeze)/stable *constantly* present and functioning all the time the same way. Then upon freeze we just copy the state of unstable - pending testing(squeeze) - frozen(squeeze, e.g together with a codename) and link new codename (e.g. wheezy) against testing. NB I am having some deja vu that 'frozen' used to be used explicitly in the archive... is that so? Then unstable/testing would roll further as usual, and pending-frozen according to the freeze schedule. This would enable CUTs, fulfill the ideas behind LMDE to have something rolling without hickups, and users of 'testing' (and unstable) would enjoy testing/unstable the way they usually do. I understand that it would require more work, but I think benefits would overweight the burden. But I cannot be first thinking about that, and I bet there were good reasons why such approach was not taken -- could anyone enlighten/point me to the shortcomings? [1] http://www.linuxmint.com/blog/?p=1527 -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] signature.asc Description: Digital signature
