Re: A concrete proposal for rolling implementation
2011/5/5 Raphael Hertzog hert...@debian.org: On Thu, 05 May 2011, Stefano Zacchiroli wrote: Also, having the unstable-next suite you've mention would tight more the deployment of rolling to other project mechanisms, while the rest of the proposal enjoyed much more decoupling. There's no reason why this unstable-next would be a requirement to start rolling. It's just a suggestion of how to handle package updates during the freeze. I've been disappointed at first to read that so many approve this rolling implementation that in fact is just c-u-t, constantly usable testing [1]! Outside of the freeze period it doesn't really matter and one can say rolling==cut. However, some key points added later with 'unstable-next' really completes the missing piece to call it rolling! During the freeze unstable is in a de facto freeze, but packages not suited for the next stable release in preparation could be uploaded to 'unstable-next'. The 'unstable-next' suite could be used for several purposes: 1) some packages could be picked from it for 'unstable' - testing 2) all packages from unstable-next are a candidate for rolling 3) after the final stable release all packages could be moved directly from 'unstable-next' to 'unstable'. Although #3 might not be practical without other infrastructure changes, but was the core of this discussion in debian-devel. rolling has only derived from not freezing unstable, but the initial proposal was to be able to never freeze unstable. It is my believe that by using the freeze time to upload packages as usual will help to prepare the next release by extending the pre-freeze development from 1.5 years to 2 years. To conclude, unstable-next suite (or some other name [2]) is a requirement for rolling [3]. Thanks [1] although the CUT team might have a different view for 'cut', I don't know what's the current direction [2] but not experimental [3] I agree with Raphael that is not a requirement to *start* rolling -- 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/banlktin3czqjafzsk1bsk6akd_w22yc...@mail.gmail.com
Re: A concrete proposal for rolling implementation
On May 9, 2011 08:48:25 am Teodor MICU wrote: To conclude, unstable-next suite (or some other name [2]) is a requirement for rolling [3]. Thanks [2] but not experimental ...unless the nature of experimental is changed, and its current function replaced with PPA's? - 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/201105091136.05627.bms...@shaw.ca
Re: A concrete proposal for rolling implementation
Hi Teodor/Bruce, On Mon, May 09, 2011 at 05:48:25PM +0300, Teodor MICU wrote: I've been disappointed at first to read that so many approve this rolling implementation that in fact is just c-u-t, constantly usable testing [1]! Outside of the freeze period it doesn't really matter and one can say rolling==cut. On Mon, May 09, 2011 at 11:36:04AM -0600, Bruce Sass wrote: On May 9, 2011 08:48:25 am Teodor MICU wrote: To conclude, unstable-next suite (or some other name [2]) is a requirement for rolling [3]. ...unless the nature of experimental is changed, and its current function replaced with PPA's? DEP-10 is focused entirely on how we can avoid and/or circumvent the freeze process (for things not concerning the next stable release), which is helpful by itself but also a key part of a working rolling release, I'd say. I'm trying to cover most of the ideas discussed in the previous mega-thread for how this could be done, including both of the unstable-updates and the PPA's approach, and maybe a couple more. I'm still putting meat onto the document but in the next couple days I'll bring it back on list for a more thorough discussion. So please keep any ideas you have about either of these approaches readily available :) sean -- 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/20110510055244.ga21...@cobija.connexer.com
Re: A concrete proposal for rolling implementation
On Fri, May 06, 2011 at 00:36:23 (CEST), Russ Allbery wrote: Steve Langasek vor...@debian.org writes: On Thu, May 05, 2011 at 10:39:29AM -0700, Russ Allbery wrote: Yes, during the freeze I ran into trouble with OpenAFS because I had too many different streams that I wanted to test at the same time. I was using experimental for the upcoming 1.6 release, which I really wanted to have available in Debian for people to test but which is a huge technological change, and there were also new stable 1.4 releases that (in a rolling model) should have gone into unstable and then into rolling. But I was holding unstable free to handle point fixes for testing. We do have testing-proposed-updates as a mechanism for getting updates into testing when unstable contains packages not suitable for release. Under these circumstances, wouldn't it have been better to upload the new 1.4 releases to unstable and use testing-proposed-updates for any critical issues that came up? Maybe we've simply become too conservative about keeping the unstable-testing path unblocked, when we should be relying more on t-p-u (which AFAICS, is more reliable now than it was when I was RM)? I considered it, but I'm really worried about t-p-u not getting enough testing. Maybe enough people are now using proposed-updates during freeze testing that it's not an issue. The stuff going into stable is what needs to be tested the most heavily; I wasn't as worried about the new 1.4 releases, since they were going to have plenty of time to be tested anyway. This anectode makes me wonder if t-p-u (or some suitable alias) should be enabled by default. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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/87tyd8z4qn@faui44a.informatik.uni-erlangen.de
Re: A concrete proposal for rolling implementation
On 04/05/11 at 22:19 +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Use case: During freeze, there's a library transition in unstable, and a new upstream version in unstable. You want to get the new upstream version into rolling (not testing), but you can't because it would pull the whole transition. So you need a way to upload the new upstream version linked against the libraries in rolling. - 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/20110505062334.ga3...@xanadu.blop.info
Re: A concrete proposal for rolling implementation
Hi, On Wed, 04 May 2011, sean finney wrote: It's an excellent idea. Some of the initial feedback that I've gotten about DEP-10 (in particular some brainstorming on IRC with Carsten Hey) is pointing at ideas along these lines, and I hope to flush them out in a bit more detail RSN. But I think it's particularly exciting that these two ideas (rolling, and dealing with freezes) might not conflict with each other, and perhaps complement one another. One issue that would need to be addressed with experimental is that opening a migration route anywhere out of experimental might come as an unpleasant surprise to some, since there's a standing expectation that it's a pseudo-suite where we can put stuff that we don't necessarily want to try out in unstable. Not an insurmountable problem (either we change that or introduce yet another psuedo-suite for this purpose), but worth note anyway. Yeah, experimental is not really the good place. We really want in rolling only packages where we have the assurance that they will land in unstable the day after the release (so automatically and not with a manual source upload). So I'd favor some sort of unstable overlay that is not experimental. It could be called unstable-next and could be auto-generated from uploads targetting unstable that introduce a new upstream version. That way by default unstable doesn't move forward with new upstream version and can always be used to upload bugfixes targetting testing. Auto-building in unstable-next would be like experimental, i.e. it would be built in unstable so that it's still possible to pick packages there in the rare case where a new upstream version is desired late in the release cycle. I like where this is going! :) Cheers, -- Raphaël Hertzog ◈ Debian Developer 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/20110505064610.gd30...@rivendell.home.ouaza.com
Re: A concrete proposal for rolling implementation
Le jeudi 05 mai 2011 à 08:23 +0200, Lucas Nussbaum a écrit : Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Use case: During freeze, there's a library transition in unstable, and a new upstream version in unstable. You want to get the new upstream version into rolling (not testing), but you can't because it would pull the whole transition. You don’t need to pull the whole transition, that’s the point of my proposal. You just need to put the library being transitioned and your package. So you need a way to upload the new upstream version linked against the libraries in rolling. Alternatively, if testing is so broken you need that new upstream version and it can build against the testing libraries, you can use testing-proposed-updates - in all cases, for both testing and rolling, a targeted fix being preferable. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: A concrete proposal for rolling implementation
On 05/05/11 at 08:51 +0200, Josselin Mouette wrote: Le jeudi 05 mai 2011 à 08:23 +0200, Lucas Nussbaum a écrit : Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Use case: During freeze, there's a library transition in unstable, and a new upstream version in unstable. You want to get the new upstream version into rolling (not testing), but you can't because it would pull the whole transition. You don’t need to pull the whole transition, that’s the point of my proposal. You just need to put the library being transitioned and your package. So you need a way to upload the new upstream version linked against the libraries in rolling. Alternatively, if testing is so broken you need that new upstream version and it can build against the testing libraries, you can use testing-proposed-updates - in all cases, for both testing and rolling, a targeted fix being preferable. That might not be the preferred solution during freeze. I am not sure of how testing-proposed-updates works. Could we: 1. upload package 1.1-1 (the new upstream we want in rolling) to testing-proposed-updates 2. accept package 1.1-1 into rolling 3. upload package 1.0-2 (new version of the package currently in testing, with a targeted fix) to testing-proposed-updates 4. accept package 1.0-2 into testing ? I'm not saying that rolling-proposed-updates should be used frequently, but it sounds more comfortable to have it at hand. Of course, we could also decide to add it later. 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/20110505065831.ga5...@xanadu.blop.info
Re: A concrete proposal for rolling implementation
On 05/05/2011 08:50 AM, Pierre Habouzit wrote: On Thu, May 05, 2011 at 12:05:22AM +0300, Cristian Henzel wrote: What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Again, no disruption: people can keep on breaking some pieces of experimental, but if they want some other pieces to be useful for rolling users, they just need to be committed to more carefulness and to add them to the override file. I also find this a very good implementation, although I would like a 'true' rolling release, without any freezes at all. I'm not sure how much extra work it implies or how much sense it would make to have an exact clone of testing just without the freezes. Not a lot, I don't expect it larger than having to place a dozen hints usually, up to a small hundred during the peaks (100 is less than 1% of our source packages). Maintaining something like that isn't hard, it's already what the RM Team does to follow testing migrations, and if rolling is generated after testing is, the Rolling Team will benefit from the RT work so it's just an incremental effort. Nothing wasted. (And not wanting to finger point but I've read at least a certain RT Member saying that he would even consider help a Rolling Team as he's already doing that pinning on his workstation…) I just thought that most DDs would have more important stuff to do during freezes than cherry-picking packages from unstable to rolling, thus a clone of testing minus the freezes, if done right, might mean a lot less work in that regard. -- Best regards, Mit freundlichen Grüßen, Cristian Henzel -- 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/4dc247a6.7050...@b3r3.info
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 08:58:31AM +0200, Lucas Nussbaum wrote: On 05/05/11 at 08:51 +0200, Josselin Mouette wrote: Le jeudi 05 mai 2011 à 08:23 +0200, Lucas Nussbaum a écrit : Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Use case: During freeze, there's a library transition in unstable, and a new upstream version in unstable. You want to get the new upstream version into rolling (not testing), but you can't because it would pull the whole transition. You don’t need to pull the whole transition, that’s the point of my proposal. You just need to put the library being transitioned and your package. So you need a way to upload the new upstream version linked against the libraries in rolling. Alternatively, if testing is so broken you need that new upstream version and it can build against the testing libraries, you can use testing-proposed-updates - in all cases, for both testing and rolling, a targeted fix being preferable. That might not be the preferred solution during freeze. I am not sure of how testing-proposed-updates works. Could we: 1. upload package 1.1-1 (the new upstream we want in rolling) to testing-proposed-updates 2. accept package 1.1-1 into rolling 3. upload package 1.0-2 (new version of the package currently in testing, with a targeted fix) to testing-proposed-updates 4. accept package 1.0-2 into testing ? I'm not saying that rolling-proposed-updates should be used frequently, but it sounds more comfortable to have it at hand. Of course, we could also decide to add it later. Frankly I'd say that the simple proposal could be implemented like tomorrow, and we could see how well it fares, and refine it when we understand its dynamics. Right now there are too many what if, the simple proposal made of a second britney run + forces is non intrusive, can be done on a d.net host easily enough, and we could learn this way how it works in practice. Sounds better than over engineering. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110505070728.ga27...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 09:07:28AM +0200, Pierre Habouzit wrote: On Thu, May 05, 2011 at 08:58:31AM +0200, Lucas Nussbaum wrote: On 05/05/11 at 08:51 +0200, Josselin Mouette wrote: Le jeudi 05 mai 2011 à 08:23 +0200, Lucas Nussbaum a écrit : Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Use case: During freeze, there's a library transition in unstable, and a new upstream version in unstable. You want to get the new upstream version into rolling (not testing), but you can't because it would pull the whole transition. You don’t need to pull the whole transition, that’s the point of my proposal. You just need to put the library being transitioned and your package. So you need a way to upload the new upstream version linked against the libraries in rolling. Alternatively, if testing is so broken you need that new upstream version and it can build against the testing libraries, you can use testing-proposed-updates - in all cases, for both testing and rolling, a targeted fix being preferable. That might not be the preferred solution during freeze. I am not sure of how testing-proposed-updates works. Could we: 1. upload package 1.1-1 (the new upstream we want in rolling) to testing-proposed-updates 2. accept package 1.1-1 into rolling 3. upload package 1.0-2 (new version of the package currently in testing, with a targeted fix) to testing-proposed-updates 4. accept package 1.0-2 into testing ? I'm not saying that rolling-proposed-updates should be used frequently, but it sounds more comfortable to have it at hand. Of course, we could also decide to add it later. Frankly I'd say that the simple proposal could be implemented like tomorrow, and we could see how well it fares, and refine it when we understand its dynamics. Right now there are too many what if, the simple proposal made of a second britney run + forces is non intrusive, can be done on a d.net host easily enough, and we could learn this way how it works in practice. Sounds better than over engineering. What I expect to be needed is to make rolling a real suite that retains packages. That will probably be needed sometimes. Though packages only in rolling should be a transitory situation that the rolling team is expected to minimize. This is a situation that does exist on the setups of our users already, like Samuel Thibault said on IRC where I said that first let's just factorize that fact and try to minimize the amount of between-testing-and-unstable setups out there to something that we manage and understand. r-p-u sounds like a can of worms. Maintainers are supposed to care about testing. Caring about rolling is just basically the same, and occasionally I wouldn't be shocked if the rolling team asked for a rolling targgetted fix to be uploaded to unstable, let it live just the day for it to be pinned in rolling, and let the maintainer continue its usual business. Again I don't expect rolling (but only experience can confirm that) pinning more than a few dozens packages, and r-p-u is probably an overkill (*and* is a bad feature, this is exactly the kind of stuff that I disliked in the early discussions about rolling: duplicating the effort for maintainers and similar issues). -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110505072208.gb27...@madism.org
Re: A concrete proposal for rolling implementation
On Wednesday, May 04, 2011 04:58:31 PM Scott Kitterman wrote: On Wednesday, May 04, 2011 04:25:35 PM Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Yes, absolutely. This seems straightforward, elegant, and useful as it encourages maintainer to push their changes to the Debian archive and make them visible and testable to rolling users, even when unstable is de facto closed. Does this mean Experimental should be renamed Unfrozen? I got asked offlist if there was a serious point here. There was, so to put it more seriously: Currently Experimental is the place to upload things not ready for use except under very narrow circumstances. It gets abused as a place for new versions during freeze as it is, but if it's the defined path into Rolling during freezes then there's a need to separate these two functions, IMO. Scott K -- 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/201105050721.29879.deb...@kitterman.com
Re: A concrete proposal for rolling implementation
Scott Kitterman wrote: Currently Experimental is the place to upload things not ready for use except under very narrow circumstances. It gets abused as a place for new versions during freeze as it is, but if it's the defined path into Rolling during freezes then there's a need to separate these two functions, IMO. If it's not ready for use except under very narrow circumstances, why upload to the Debian archive (rather than a patch to a bug report, say) at all? I personally don't think uploading packages to experimental before it is time for them to participate in transitions to testing and integrate with the rest of the next stable distribution is abuse at all. In fact I wish people would do it more often. -- 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/20110505120339.GA26901@elie
Re: A concrete proposal for rolling implementation
On Thursday, May 05, 2011 08:03:39 AM Jonathan Nieder wrote: Scott Kitterman wrote: Currently Experimental is the place to upload things not ready for use except under very narrow circumstances. It gets abused as a place for new versions during freeze as it is, but if it's the defined path into Rolling during freezes then there's a need to separate these two functions, IMO. If it's not ready for use except under very narrow circumstances, why upload to the Debian archive (rather than a patch to a bug report, say) at all? I personally don't think uploading packages to experimental before it is time for them to participate in transitions to testing and integrate with the rest of the next stable distribution is abuse at all. In fact I wish people would do it more often. I'll grant you abuse is too strong a term, but that doesn't change that if Experimental is suddenly in the path to Rolling during a freeze it is less useful for the traditional function of being 'experimental'. Scott K -- 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/201105050809.23907.deb...@kitterman.com
Re: A concrete proposal for rolling implementation
Jonathan Nieder jrnie...@gmail.com (05/05/2011): I personally don't think uploading packages to experimental before it is time for them to participate in transitions to testing and integrate with the rest of the next stable distribution is abuse at all. In fact I wish people would do it more often. Being able to tell bug reporters “please check what happens with the X stack in experimental” (which had more or less latest upstream release candidates or releases), and closing with those versions; or forwarding upstream if bugs are still there, is something I find very interesting indeed. And last I checked, upstreams were happy not to receive a massive flow of bug reports for already-fixed bugs, so that they could concentrate on current issues. Mraw, KiBi. signature.asc Description: Digital signature
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 08:46:10AM +0200, Raphael Hertzog wrote:
Yeah, experimental is not really the good place. We really want in
rolling only packages where we have the assurance that they will land
in unstable the day after the release (so automatically and not with
a manual source upload).
Isn't the ability to copy .changes file around suites a completely
orthogonal problem? I'd love to have the ability, on demand, to
upload a package which is currently in experimental to unstable, no
matter rolling. If we had that ability, we can leave up to maintainers
the ability to do .changes-only upload to unstable the day after a
release, no matter if the former sources upload targeted unstable or
r-p-u/unstable-next/experimental/whatever.
I don't think it'd be reasonable to have scenarios in which I might have
uploaded to one such suite 1.5 years ago and having that upload be
scheduled for as long as that automatically to unstable the day after
the release. Having the maintainer to choose that sounds much better.
Yes, nowadays that is painful to do, but due to the lack of
.changes-only upload.
Also, having the unstable-next suite you've mention would tight more the
deployment of rolling to other project mechanisms, while the rest of the
proposal enjoyed much more decoupling.
(Yes, all this are minor points, but since it's being discussed... :-))
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{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. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: A concrete proposal for rolling implementation
Pierre Habouzit madco...@madism.org writes: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandoraâs box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they donât help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? Say you have just uploaded a new upstream release to unstable and then someone reports a RC bug against testing. Pushing this untested version into rolling isn't the right thing. Would a t-p-u upload get added to rolling quickly too in those cases? What if testing is frozen? MfG Goswin -- 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/878vulytt4.fsf@frosties.localnet
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandoraâs box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they donât help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? Say you have just uploaded a new upstream release to unstable and then someone reports a RC bug against testing. Pushing this untested version into rolling isn't the right thing. Would a t-p-u upload get added to rolling quickly too in those cases? What if testing is frozen? I'd say let's see with the reality if it works or not. It's clear that rolling will have RC bugs. The question is will it be bearable or not. I think so. with what if discussions we'll go nowhere, that's why I'd be in favor of a small experiment with the smallest amount of work to be done (my just use a britney to chose between unstable and testing and nothing more proposal), and see how well/bad that performs. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110505170545.gf19...@madism.org
Re: A concrete proposal for rolling implementation
Cyril Brulebois k...@debian.org writes: Jonathan Nieder jrnie...@gmail.com (05/05/2011): I personally don't think uploading packages to experimental before it is time for them to participate in transitions to testing and integrate with the rest of the next stable distribution is abuse at all. In fact I wish people would do it more often. Being able to tell bug reporters “please check what happens with the X stack in experimental” (which had more or less latest upstream release candidates or releases), and closing with those versions; or forwarding upstream if bugs are still there, is something I find very interesting indeed. Yes, during the freeze I ran into trouble with OpenAFS because I had too many different streams that I wanted to test at the same time. I was using experimental for the upcoming 1.6 release, which I really wanted to have available in Debian for people to test but which is a huge technological change, and there were also new stable 1.4 releases that (in a rolling model) should have gone into unstable and then into rolling. But I was holding unstable free to handle point fixes for testing. We have a ton of archives right now, and I'm hesitant to even hint at adding another one, but it does sometimes feel like we have one too few. -- 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/87tyd9gi7i@windlord.stanford.edu
Re: A concrete proposal for rolling implementation
* Pierre Habouzit [2011-05-05 07:46 +0200]: On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote: If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? That's the point, you don't target rolling, your goal is still to make stuff migrate into testing, rolling is just the extra few packages testing needs to fix the most important breakages that happen (e.g. your PAM example, or large migrations where dependencies across libraries are too loose and break testing, Joss said it happens to gnome quite a lot e.g.). So rolling would principally also be frozen during testing's freeze, this is not what the name seems to imply. Unlike variants where rolling would really roll, this one does not require an additional pseudo-suite in Debian [1] and could be implemented on rolling.debian.net without convincing the release team and ftpmaster first. Regards Carsten [1] experimental would even with a way for maintainers to add a hint to their packages to let them migrate from experimental to rolling be the wrong one because of its low pinning. -- 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/20110505174845.ga15...@furrball.stateful.de
Re: A concrete proposal for rolling implementation
On Thu, 05 May 2011, Stefano Zacchiroli wrote: On Thu, May 05, 2011 at 08:46:10AM +0200, Raphael Hertzog wrote: Yeah, experimental is not really the good place. We really want in rolling only packages where we have the assurance that they will land in unstable the day after the release (so automatically and not with a manual source upload). Isn't the ability to copy .changes file around suites a completely orthogonal problem? Yes it is. I don't think it'd be reasonable to have scenarios in which I might have uploaded to one such suite 1.5 years ago and having that upload be scheduled for as long as that automatically to unstable the day after the release. That's a problem only if you mix stuff in experimental. If you have a repository dedicated to such updates that are supposed to end up in unstable, it's no longer problematic (and I doubt we would have a freeze of 1.5 year ;-)). Also, having the unstable-next suite you've mention would tight more the deployment of rolling to other project mechanisms, while the rest of the proposal enjoyed much more decoupling. There's no reason why this unstable-next would be a requirement to start rolling. It's just a suggestion of how to handle package updates during the freeze. Cheers, -- Raphaël Hertzog ◈ Debian Developer 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/20110505183031.gc31...@rivendell.home.ouaza.com
Re: A concrete proposal for rolling implementation
On Thu, 05 May 2011 10:39:29 -0700, Russ Allbery wrote: Being able to tell bug reporters “please check what happens with the X stack in experimental” (which had more or less latest upstream release candidates or releases), and closing with those versions; or forwarding upstream if bugs are still there, is something I find very interesting indeed. Assuming that experimental would change its character -- would a PPA (or whatever it's called) satisfy this legitimate concern? We have a ton of archives right now, and I'm hesitant to even hint at adding another one, but it does sometimes feel like we have one too few. Same idea: Would an experimental suite that's filled during the freeze to keep unstable free for RC bug fixes and migrates after the thaw plus (a) PPA(s) for experimenting (sic!) with newer releases help here? Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Red Hot Chili Peppers: If signature.asc Description: Digital signature
Re: A concrete proposal for rolling implementation
On Thu, 05 May 2011 17:46:34 +0200, Stefano Zacchiroli wrote: Yeah, experimental is not really the good place. We really want in rolling only packages where we have the assurance that they will land in unstable the day after the release (so automatically and not with a manual source upload). Ack, especially in the automatic part. Isn't the ability to copy .changes file around suites a completely orthogonal problem? I'd love to have the ability, on demand, to upload a package which is currently in experimental to unstable, no matter rolling. Putting my pkg-perl hat on: Manually moving packages doesn't scale for almost 2000 packages in total and ~5 new upstream releases per day. I'd really love a clean possibility to (1) upload new upstream release during the freeze (2) without polluting unstable as the staging area for RC bugs fixes in testing and (3) auto-migration after the thaw. If this means redefining experimental (and using PPAs for the current experimental uploads) or creating a new unstable-next suite as proposed by Raphaël doesn't look crucial to me. Cheers, gregor, who enjoys this constructive discussion -- .''`. Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Funny Van Dannen: Sexualitaet signature.asc Description: Digital signature
Re: A concrete proposal for rolling implementation
gregor herrmann gre...@debian.org writes: Same idea: Would an experimental suite that's filled during the freeze to keep unstable free for RC bug fixes and migrates after the thaw plus (a) PPA(s) for experimenting (sic!) with newer releases help here? Yes, absolutely. And PPAs would be really helpful for filling that gap, even if we didn't have experimental migration to unstable. -- 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/878vukhpx1@windlord.stanford.edu
Re: A concrete proposal for rolling implementation
On 12471 March 1977, Stefano Zacchiroli wrote: What I expect to be needed is to make rolling a real suite that retains packages. That will probably be needed sometimes. Though packages only in rolling should be a transitory situation that the rolling team is expected to minimize. Early on in the CUT discussions on the cut-team mailing lists, I seem to remember---although I can't find a reference to that right now---ftp-master saying that to have a new suite it's enough to hand them a self-contained list of package/version pairs. Of course I've no idea whether they'd agree in doing that for rolling as it's being described here, but technically there are most likely little obstacles to that. IANAF-M. Generally speaking, for a suite managed by someone else, in the way of testing, we need a list containing package version architecture lines (where architecture includes source and all). We don't care how one gets to this list. We also need some knowledge about various suite properties (see table suite in projectb) as well as version constraints (does it have to be newer than experimental? older than stable? both at the same time?). And it also wants to have something sane responsible for it. That is, a team, somewhat defined, which is responsible for whatever ends up in the suite. Which we can skin alive if needed. Something like that. Obviously we do not want a million of suites. Every extra suite costs time and work to maintain it. (This WILL be a bit different as soon as we fleshed out a PPA like thing inside dak, which we currently draft a how this could look and work, but more on that later, when its ready to discuss) -- bye, Joerg I'm convinced that the ftpmaster team are ninjas -- they do their stuff, but they do it quietly and behind the scenes, so everybody thinks they're asleep at the wheel...) -- 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/87sjssx50d@gkar.ganneff.de
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 10:39:29AM -0700, Russ Allbery wrote: Cyril Brulebois k...@debian.org writes: Jonathan Nieder jrnie...@gmail.com (05/05/2011): I personally don't think uploading packages to experimental before it is time for them to participate in transitions to testing and integrate with the rest of the next stable distribution is abuse at all. In fact I wish people would do it more often. Being able to tell bug reporters “please check what happens with the X stack in experimental” (which had more or less latest upstream release candidates or releases), and closing with those versions; or forwarding upstream if bugs are still there, is something I find very interesting indeed. Yes, during the freeze I ran into trouble with OpenAFS because I had too many different streams that I wanted to test at the same time. I was using experimental for the upcoming 1.6 release, which I really wanted to have available in Debian for people to test but which is a huge technological change, and there were also new stable 1.4 releases that (in a rolling model) should have gone into unstable and then into rolling. But I was holding unstable free to handle point fixes for testing. We do have testing-proposed-updates as a mechanism for getting updates into testing when unstable contains packages not suitable for release. Under these circumstances, wouldn't it have been better to upload the new 1.4 releases to unstable and use testing-proposed-updates for any critical issues that came up? Maybe we've simply become too conservative about keeping the unstable-testing path unblocked, when we should be relying more on t-p-u (which AFAICS, is more reliable now than it was when I was RM)? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.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/20110505215638.gb19...@virgil.dodds.net
Re: A concrete proposal for rolling implementation
Steve Langasek vor...@debian.org writes: On Thu, May 05, 2011 at 10:39:29AM -0700, Russ Allbery wrote: Yes, during the freeze I ran into trouble with OpenAFS because I had too many different streams that I wanted to test at the same time. I was using experimental for the upcoming 1.6 release, which I really wanted to have available in Debian for people to test but which is a huge technological change, and there were also new stable 1.4 releases that (in a rolling model) should have gone into unstable and then into rolling. But I was holding unstable free to handle point fixes for testing. We do have testing-proposed-updates as a mechanism for getting updates into testing when unstable contains packages not suitable for release. Under these circumstances, wouldn't it have been better to upload the new 1.4 releases to unstable and use testing-proposed-updates for any critical issues that came up? Maybe we've simply become too conservative about keeping the unstable-testing path unblocked, when we should be relying more on t-p-u (which AFAICS, is more reliable now than it was when I was RM)? I considered it, but I'm really worried about t-p-u not getting enough testing. Maybe enough people are now using proposed-updates during freeze testing that it's not an issue. The stuff going into stable is what needs to be tested the most heavily; I wasn't as worried about the new 1.4 releases, since they were going to have plenty of time to be tested anyway. -- 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/87oc3gg4go@windlord.stanford.edu
Re: A concrete proposal for rolling implementation
Pierre Habouzit madco...@madism.org writes: On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening PandoraâÂÂs box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they donâÂÂt help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? Say you have just uploaded a new upstream release to unstable and then someone reports a RC bug against testing. Pushing this untested version into rolling isn't the right thing. Would a t-p-u upload get added to rolling quickly too in those cases? What if testing is frozen? I'd say let's see with the reality if it works or not. It's clear that rolling will have RC bugs. The question is will it be bearable or not. I think so. with what if discussions we'll go nowhere, that's why I'd be in favor of a small experiment with the smallest amount of work to be done (my just use a britney to chose between unstable and testing and nothing more proposal), and see how well/bad that performs. Hell, why britney? Just set up a reprepro that updates from unstable with a filter to only pull the handfull of packages rolling should have in addition / instead of testing. Then you add deb http://ftp.debian.org/debian testing main deb http://rolling.debian.net/debian rolling main and you are ready to test. I actually would really like to see that tested. If you find someone to host it I can clobber you together the filter and config for reprepro. I don't think the problem will be in creating the actual archive. Not to start testing the idea. If it uses reprepro or a trivial britney reuse or someone eventually writes a more complex DAK extention won't be the problem at the start. The problem will be in building the support team and procedures and mechanisms to tune the filter. To decide what goes into rolling and what not. Up to deciding how (if?) individual DDs should be able to mark their packages to go in. MfG Goswin -- 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/87tyd8yd56.fsf@frosties.localnet
Re: A concrete proposal for rolling implementation
On Fri, May 06, 2011 at 12:51:33AM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening PandoraâÂÂs box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they donâÂÂt help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? Say you have just uploaded a new upstream release to unstable and then someone reports a RC bug against testing. Pushing this untested version into rolling isn't the right thing. Would a t-p-u upload get added to rolling quickly too in those cases? What if testing is frozen? I'd say let's see with the reality if it works or not. It's clear that rolling will have RC bugs. The question is will it be bearable or not.. I think so. with what if discussions we'll go nowhere, that's why I'd be in favor of a small experiment with the smallest amount of work to be done (my just use a britney to chose between unstable and testing and nothing more proposal), and see how well/bad that performs. Hell, why britney? To compute something that is actually installable and maximizes the installability count doh! -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110505225350.gb...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 07:48:45PM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-05 07:46 +0200]: On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote: If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? That's the point, you don't target rolling, your goal is still to make stuff migrate into testing, rolling is just the extra few packages testing needs to fix the most important breakages that happen (e.g. your PAM example, or large migrations where dependencies across libraries are too loose and break testing, Joss said it happens to gnome quite a lot e.g.). So rolling would principally also be frozen during testing's freeze, this is not what the name seems to imply. Unlike variants where rolling would really roll, this one does not require an additional pseudo-suite in Debian [1] and could be implemented on rolling.debian.net without convincing the release team and ftpmaster first. There have been several DDs on -devel@ epressing concerns about the fact that having something unfreezed during the freeze would divert the attention from the release and many people don't want it to happen (including me). OTOH if Debian is more tested before the freeze thanks to rolling, it can help to reduce the freeze length… -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110505230603.gc...@madism.org
Re: A concrete proposal for rolling implementation
[Josselin Mouette, 2011-05-04] This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. +1 [...] What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. I'm not interested in helping f.e. with Perl bugs so once the ones I care about are fixed, I just want to focus on Sid (i.e. upload new upstream versions, prepare new transitions etc.) - I can wait a month or two, but these long freezes demotivate me a lot. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20110504132207.gm17...@piotro.eu
Re: A concrete proposal for rolling implementation
Piotr Ożarowski wrote: [Josselin Mouette, 2011-05-04] This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. +1 [...] What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. I'm not interested in helping f.e. with Perl bugs so once the ones I care about are fixed, I just want to focus on Sid (i.e. upload new upstream versions, prepare new transitions etc.) - I can wait a month or two, but these long freezes demotivate me a lot. While I agree with the demotivation stance, why can't those packages be uploaded to experimental, fwiw ? -- 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/iprk5f$hgt$1...@dough.gmane.org
Re: A concrete proposal for rolling implementation
Hi, I came to the same conclusion than you after the discussion we had in the comments of your article. I think it's the right approach. I still have a few comments though. On Wed, 04 May 2011, Josselin Mouette wrote: It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. I think you meant what's broken in testing (i.e. you take a few selected packages from unstable to fix bugs present in testing). This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. It doesn't need to be a pseudo-suite. It's a collection of packages taken in testing or unstable, it's not more complicated to make it a full suite. And PR-wise, it's way better to avoid testing appearing in the sources.list. Also it means that the day where we have improved our processes in unstable/testing so that rolling is no longer necessary, we can simply merge testing and rolling in a single suite. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up Why powerpc? If we really take more than i386/amd64 for rolling, there are more users of armel than of powerpc. packages from unstable. Typically it would be generated from an override file that looks like: source-package version xserver-xorg-video-ati 1.2.3-4 ... The rolling suite would try to have a package that has *at least* this version. If it is found in testing, the package is removed from rolling. If otherwise it is found in unstable, the package is picked from unstable. You still need some sort of britney to verify that the package is effectively installable in rolling, and to verify you're not breaking installability of other packages available in rolling. But yes the basic principle is to stay as close to testing as possible, to get as much as possible fixed via testing (in particular when it's possible to fix via an updated version pushed through t-p-u) and for the rest to cherry-pick some updates from unstable. Once we diverged from testing, there's the question of what to do when the package gets updated in unstable. By default the answer is nothing unless the updated package fix a RC bug that is not present in testing but that was introduced since then (and is now present in the rolling version). Why I like it - First of all, this idea doesn’t affect *at all* the current release process. It just takes people willing to maintain the override file - and we could even choose to let any DD modify it. And it’s much faster to modify such a file than telling every user from testing that they have to upgrade to the unstable version. I don't believe in the let any DD modify it but there should be a simple way for DD to evaluate and submit such requests of integration into rolling. And just as importantly, I think it should just work. There’s very little chance that people get completely hosed systems like it happens sometimes for unstable. There are all chances that something broken in testing can be fixed by pulling a handful of packages from unstable. I agree with this. There might some corner-cases where we might require direct uploads into rolling but if we stick to i386/amd64, it's easy enough to do even without specific support on the buildd side. What to do during freezes - I leave that aside for now. Your proposal covers the need to push newer upstream versions to users but doesn't respond to the desire of developers to continue development. But it's really another discussion so I prefer to not discuss it in that thread. What do you think? +1 from me. Thank you for the proposal! Cheers, -- Raphaël Hertzog ◈ Debian Developer 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/20110504133040.gb24...@rivendell.home.ouaza.com
Re: A concrete proposal for rolling implementation
[Didier Raboud, 2011-05-04] While I agree with the demotivation stance, why can't those packages be uploaded to experimental, fwiw ? because that's not what experimental is for and it's harder to use it (did you notice that python3.2 is in experimental or did someone gave you proper apt-pinning rule when Squeeze was frozen?) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20110504133210.gn17...@piotro.eu
Re: A concrete proposal for rolling implementation
Le mercredi 04 mai 2011 à 15:30 +0200, Raphael Hertzog a écrit : On Wed, 04 May 2011, Josselin Mouette wrote: It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. I think you meant what's broken in testing (i.e. you take a few selected packages from unstable to fix bugs present in testing). Yes, of course. It doesn't need to be a pseudo-suite. It's a collection of packages taken in testing or unstable, it's not more complicated to make it a full suite. It cannot be “just” a full suite. When you add a package coming from unstable, you must also keep the version that is already in testing. To follow on my example, if you allow libgnomekbd and gnome-settings-daemon from unstable, you still need libgnomekbd from testing, otherwise other packages will become uninstallable. And PR-wise, it's way better to avoid testing appearing in the sources.list. That’s really an implementation detail. If you really want to hide it, you just need to ensure rolling can have two versions of the same sources at the same time. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up Why powerpc? If we really take more than i386/amd64 for rolling, there are more users of armel than of powerpc. Yes, sure. It was just an example. You still need some sort of britney to verify that the package is effectively installable in rolling, and to verify you're not breaking installability of other packages available in rolling. If rolling is just an overlay on testing, I don’t think that’s necessary. The worst that could happen is that the version in rolling is uninstallable, but the version in testing would still be. What the britney-like thing could do is bring automatically all dependencies that are actually necessary for the package to be installable. But this could also make things more complicated, since britney tests source packages, not binaries. You might bring a source in rolling only for a runtime that is needed, but the development header being uninstallable is not a problem. Britney would prevent that, while it would still be a good move. Once we diverged from testing, there's the question of what to do when the package gets updated in unstable. By default the answer is nothing unless the updated package fix a RC bug that is not present in testing but that was introduced since then (and is now present in the rolling version). I’m not entirely sure, but I think it’s better to pick the update from unstable instead of letting in rolling a package that is no longer available somewhere else. It should make upgrades smoother, and it should also be less work for maintainers, since it avoids having another version from which problems can arise. -- Joss -- 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/1304516627.9090.154.camel@pi0307572
Re: A concrete proposal for rolling implementation
On Wed, 04 May 2011, Josselin Mouette wrote: It doesn't need to be a pseudo-suite. It's a collection of packages taken in testing or unstable, it's not more complicated to make it a full suite. It cannot be “just” a full suite. When you add a package coming from unstable, you must also keep the version that is already in testing. To follow on my example, if you allow libgnomekbd and gnome-settings-daemon from unstable, you still need libgnomekbd from testing, otherwise other packages will become uninstallable. A full suite can have 2 versions of the same source package and can contain both libgnomekbd4 and libgnomekbd7. It's not a problem. And PR-wise, it's way better to avoid testing appearing in the sources.list. That’s really an implementation detail. If you really want to hide it, you just need to ensure rolling can have two versions of the same sources at the same time. OK. Testing already can, so it should be ok for rolling too. You still need some sort of britney to verify that the package is effectively installable in rolling, and to verify you're not breaking installability of other packages available in rolling. If rolling is just an overlay on testing, I don’t think that’s necessary. The worst that could happen is that the version in rolling is uninstallable, but the version in testing would still be. Yes but as long as it's uninstallable, the bug is not fixed for the user. So while we did not break anything, we did not fix anything either. :-) What the britney-like thing could do is bring automatically all dependencies that are actually necessary for the package to be installable. But this could also make things more complicated, since britney tests source packages, not binaries. You might bring a source in rolling only for a runtime that is needed, but the development header being uninstallable is not a problem. Britney would prevent that, while it would still be a good move. Yes, we could try to improve britney towards this. But I'm not sure it's a good idea to pick only some binary packages from a source package. It happens often enough that the package lack a strict dependency that might be required and picking all the binaries from a source package limits the risk of upgrading them separately (and thus experiencing the bug). Once we diverged from testing, there's the question of what to do when the package gets updated in unstable. By default the answer is nothing unless the updated package fix a RC bug that is not present in testing but that was introduced since then (and is now present in the rolling version). I’m not entirely sure, but I think it’s better to pick the update from unstable instead of letting in rolling a package that is no longer available somewhere else. It should make upgrades smoother, and it should also be less work for maintainers, since it avoids having another version from which problems can arise. In that case, those updates should follow the same rules than for testing itself. It would be unreasonable to accept the new unstable upload immediately. Cheers, -- Raphaël Hertzog ◈ Debian Developer 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/20110504142011.ge24...@rivendell.home.ouaza.com
Re: A concrete proposal for rolling implementation
Josselin Mouette j...@debian.org writes: This way, when something is broken in testing and cannot be unbroken quickly, a maintainer who notices it could add (or make the people in charge add) the necessary packages to the override file. If, for a reason or another, an important bug fix or a security update doesnât propagate to testing quickly enough, you can now just add it and the necessary dependencies to rolling, and people using it arenât affected. Whenever the affected packages finally migrate to testing, the discrepancy between rolling and testing automatically disappears. That sounds like a nice idea. Maybe call it hot-fix instead of rolling. :) I would suggest one more thing though. Sometimes it is know that a package breaks on upgrade and maybe even causes data loss. But the fix might not be aparent or quick to implement. Maybe it would be nice if one could then also remove or block a package so people won't upgrade to the known bad version while the maintainer works on a fix. Note: this would prbably require a full Packages file and people to only add rolling to sources.list without also having testing. MfG Goswin -- 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/87fwoua6oo.fsf@frosties.localnet
Re: A concrete proposal for rolling implementation
Piotr Ożarowski dijo [Wed, May 04, 2011 at 03:22:07PM +0200]: [Josselin Mouette, 2011-05-04] This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. +1 I'll also state it: Josselin's proposal looks very interesting, simple and compatible with what we have now! [...] What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. I'm not interested in helping f.e. with Perl bugs so once the ones I care about are fixed, I just want to focus on Sid (i.e. upload new upstream versions, prepare new transitions etc.) - I can wait a month or two, but these long freezes demotivate me a lot. For many bugs, it's not only that I'm not interested, but I'm also disqualified. Of course, a long freeze can be demotivating, and it can also cause a spike of work when we reopen unstable for anything goes uploads. In my case, I used this last freeze to redo the packaging for one of my complex packages, and kept up-to-date with upstream via experimental - So I was breaking stuff and keeping up to date at the same time. It cannot always work like this, of course, I'm just mentioning a way to keep the fun flowing while in freeze. Now, long freezes are complicated, true. But I don't think keeping unstable disconnected from (frozen|testing) will really help us. If all uploads during the freeze have to go through t-p-u, we will lose a bit of what gives coherence to the whole system. I feel, as many others have stated, that the Squeeze release cycle was quite a successful one, even with some erupting flames here and there... Probably we should focus more on keeping the bug count lower during the non-freezing period? That should surely lead to a shorter freeze period. -- 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/20110504153025.gc15...@gwolf.org
Re: A concrete proposal for rolling implementation
Hi, (you already know, but let's state that on dd@ too) Josselin Mouette j...@debian.org (04/05/2011): during the recent discussions about rolling, a proposal was made in a blog comment, and after giving it some quick thoughts, most people I’ve talked with seem to think it is a good idea, so it’s time for it to be discussed at large. It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. your proposal certainly makes a lot of sense. Having to quick-fetch packages from unstable to avoid long-term breakages seems to be the major issue for prospective testing users, and “automating” (whatever the details) that pinning seems like an easy and non-disruptive (as far as the testing process is concerned -- AFAICT, IMVHO, etc.) way to fix that major usability issue. Thank you for coming with that concrete proposal. Mraw, KiBi. signature.asc Description: Digital signature
Re: A concrete proposal for rolling implementation
Le mercredi 04 mai 2011 à 16:20 +0200, Raphael Hertzog a écrit : A full suite can have 2 versions of the same source package and can contain both libgnomekbd4 and libgnomekbd7. It's not a problem. OK, so I officially do not care a shit™. What the britney-like thing could do is bring automatically all dependencies that are actually necessary for the package to be installable. But this could also make things more complicated, since britney tests source packages, not binaries. You might bring a source in rolling only for a runtime that is needed, but the development header being uninstallable is not a problem. Britney would prevent that, while it would still be a good move. Yes, we could try to improve britney towards this. But I'm not sure it's a good idea to pick only some binary packages from a source package. It happens often enough that the package lack a strict dependency that might be required and picking all the binaries from a source package limits the risk of upgrading them separately (and thus experiencing the bug). Indeed. The appropriate result to obtain would be something like: “the list of source packages you need to pull for a given binary package to be installable”. I’m not entirely sure, but I think it’s better to pick the update from unstable instead of letting in rolling a package that is no longer available somewhere else. It should make upgrades smoother, and it should also be less work for maintainers, since it avoids having another version from which problems can arise. In that case, those updates should follow the same rules than for testing itself. It would be unreasonable to accept the new unstable upload immediately. I don’t think it would be entirely unreasonable, since we’re already in the case of a specific package we had to pull from unstable, to expect the maintainer to be careful enough. Don’t forget that we’re talking about probably a dozen of packages at a given time. Of course, having a delay before accepting the package seems sensible too, so it’s not like I really care. -- Joss -- 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/1304524993.9090.298.camel@pi0307572
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. This is an excellente proposal which technically can be implemented this way: - having a new britney instance, which is chained to the result of the testing britney. - it is fed with a new hint file composed of forced migrations (those are versionned), feeding the result of the testing britney with sid. - result is a new release only made of testing or unstable packages. If you find the people wanting to make up the rolling team, I think it's a few hours work to setup (and overhead on the ftp servers would just be minimal: a new suite and associated Packages files, nothing more). Doing it this way: - leverages the same tools as what we have now (britney, dak); - only uses packages either in unstable or testing, which makes rolling a glorified Pin-file hence people using rolling don't diverge from the stable release work and are actually *worthwile* bug reporters and gives more coverage on testing *excellent*. - benefits from the release work: e.g. if a package is removed from testing, since rolling is recreated from that, it inherits that (nothing prevents the rolling team to force it back for whichever reason). - allows to take snapshots of rolling on a semi-regular basis (with associated d-i releases). E.g. every 3 months or so. Those would be alphas before the freeze, and betas during the freeze. I like it a lot, I'm even finding it useful: it looks like it resolves the rolling issues for people (wrt having something like a 'Usable' testing), but doesn't really forks testing, only glorified pinning managed at the project level instead of on each other's machines. But it doesn't make those users worthless to the release team, quite the contrary. It could even turn-up to become a useful release tool. I just love that proposal. At least something technical that makes sense, thanks Joss. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110504161129.gh27...@madism.org
Re: A concrete proposal for rolling implementation
Hi, Josselin Mouette j...@debian.org writes: The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up packages from unstable. Typically it would be generated from an override file that looks like: source-package version xserver-xorg-video-ati 1.2.3-4 I don't think this needs to be restricted to a subset of architectures when you allow rolling to pick different versions[1] for each arch. [1] including none if the required version is not available in unstable A concrete example -- Let’s imagine something that might happen soon (although of course we will try hard for it not to happen): a new version of nautilus migrates to testing, but it was missing a Breaks - it doesn’t work with the version of gnome-settings-daemon in testing. The new gnome-settings-daemon in unstable works, but it won’t migrate because there is a libgnomekbd transition in progress, and gnome-screensaver which is part of the transition doesn’t build on s390. In this case, we can just add libgnomekbd and gnome-settings-daemon to the override file. Users of the rolling suite will have the two versions of libgnomekbd available, and they can update their systems to a working state. In this case, you could add the newer version to rolling for all architectures except s390. This way all users not using s390 could already upgrade to the new version. Ansgar -- 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/s2saaf2tqba@bistromathics.mathi.uni-heidelberg.de
Re: A concrete proposal for rolling implementation
On 04/05/11 at 14:24 +0200, Josselin Mouette wrote: Hi, during the recent discussions about rolling, a proposal was made in a blog comment, and after giving it some quick thoughts, most people I’ve talked with seem to think it is a good idea, so it’s time for it to be discussed at large. It starts from the following fact: if you want a testing system that works correctly, you usually have to add APT lines for unstable, while pinning them to only install specific packages you need to unbreak what’s broken in unstable. The idea is to make this process automatic. Let me elaborate. The new “rolling” suite --- This would be a pseudo-suite, like experimental. Except that while experimental is built on top of unstable and filled manually by maintainers, rolling would be built on top of testing and filled semi-automatically. A rolling system would have typically 2 APT lines: one for testing and one for rolling. The rolling suite would only exist for a subset of architectures (we could start with powerpc, i386 and amd64), generated by picking up packages from unstable. Typically it would be generated from an override file that looks like: source-package version xserver-xorg-video-ati 1.2.3-4 ... The rolling suite would try to have a package that has *at least* this version. If it is found in testing, the package is removed from rolling. If otherwise it is found in unstable, the package is picked from unstable. This way, when something is broken in testing and cannot be unbroken quickly, a maintainer who notices it could add (or make the people in charge add) the necessary packages to the override file. If, for a reason or another, an important bug fix or a security update doesn’t propagate to testing quickly enough, you can now just add it and the necessary dependencies to rolling, and people using it aren’t affected. Whenever the affected packages finally migrate to testing, the discrepancy between rolling and testing automatically disappears. The reason for the “at least” version rule is that new uploads to unstable are supposed to fix the situation in testing anyway. I don’t think we should keep in rolling packages that are no longer in unstable. While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. - 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/20110504201222.ga31...@xanadu.blop.info
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 03:30:40PM +0200, Raphael Hertzog wrote:
On Wed, 04 May 2011, Josselin Mouette wrote:
It starts from the following fact: if you want a testing system that
works correctly, you usually have to add APT lines for unstable, while
pinning them to only install specific packages you need to unbreak
what’s broken in unstable.
Thanks for the proposal, it looks really interesting!
A few comments and some potential help/directions are below.
It doesn't need to be a pseudo-suite. It's a collection of packages taken
in testing or unstable, it's not more complicated to make it a full suite.
And PR-wise, it's way better to avoid testing appearing in the
sources.list.
I don't think that the name showing up in sources.list are important for
PR reasons. The problem with the current testing marketing (for those
who buy PR arguments) is not the sources.list line, but that the suite
is called that way everywhere and advertised solely as the developer /
internal suite that it is. If we advertise rolling with that name (and
proper explanation), what is in sources.list wouldn't really matter.
Still, having a single suite sounds more flexible: we will be able to
control the whole set of rolling packages server side, no matter what is
currently in testing. Not that I can imagine a reason for doing that
now, but having that flexibility sounds good. (And you have already
discussed that it is possible to have.)
The rolling suite would only exist for a subset of architectures (we
could start with powerpc, i386 and amd64), generated by picking up
Why powerpc? If we really take more than i386/amd64 for rolling, there
are more users of armel than of powerpc.
Beside the specific choices of architectures, I'm not sure I see which
specific problem architectures bring into the game. For testing proper,
there are some architecture alignment rules that might make transition
more complex. But for rolling as it is being proposed here, it looks
like that with per-architecture overrides we can support whatever
architecture sets we please.
Are there other constraints than manpower for the overrides that I'm
overlooking? (Note: I'm not arguing that we should have rolling for all
archs, I'm just trying to understand if I've overlooked some
constraints.)
You still need some sort of britney to verify that the package is effectively
installable in rolling, and to verify you're not breaking installability
of other packages available in rolling.
If you only need installability test for binaries (and possibly even
satisfaiability of build-depends, which is currently not checked by
britney but used on buildds), edos-distcheck offers that out of the box.
It would most likely be way easier to setup than britney. For some of
the other needs expressed by Joss, we (as in Mancoosi) have most of the
code ready as well, although not necessarily packaged yet. I need to
look at the details of what Joss had in mind, but we have code ready to
answers questions like which package do I absolutely need to be
installable in that suite?.
If you want to go ahead with patching britney, by all means go ahead, as
it might provide patches useful for the main brintey as well. But if you
want to try some alternatives, we can probably help.
What do you think?
+1 from me. Thank you for the proposal!
Ditto!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{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. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: A concrete proposal for rolling implementation
Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110504202329.ga20...@madism.org
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:17:03PM +0200, Stefano Zacchiroli wrote: If you want to go ahead with patching britney, by all means go ahead, as it might provide patches useful for the main brintey as well. But if you want to try some alternatives, we can probably help. I don't think you need to patch britney at all. Just take the last testing computed as a testing-britney output as a start, have a list of force-hints to be processed, taken from unstable, and there you go. It's just a new britney run. Admitedly there is a small patch to be done, force hints in britney are strictly versionned, for the rolling case one may want to have looser way to express force hints (with version ranges e.g.), but that should't be really hard. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110504202724.gb20...@madism.org
Re: A concrete proposal for rolling implementation
* Pierre Habouzit [2011-05-04 22:23 +0200]: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? Carsten -- 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/20110504204846.ga27...@furrball.stateful.de
Re: A concrete proposal for rolling implementation
On Wednesday, May 04, 2011 04:25:35 PM Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Yes, absolutely. This seems straightforward, elegant, and useful as it encourages maintainer to push their changes to the Debian archive and make them visible and testable to rolling users, even when unstable is de facto closed. Does this mean Experimental should be renamed Unfrozen? Scott K -- 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/201105041658.32267.deb...@kitterman.com
Re: A concrete proposal for rolling implementation
What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Again, no disruption: people can keep on breaking some pieces of experimental, but if they want some other pieces to be useful for rolling users, they just need to be committed to more carefulness and to add them to the override file. I also find this a very good implementation, although I would like a 'true' rolling release, without any freezes at all. I'm not sure how much extra work it implies or how much sense it would make to have an exact clone of testing just without the freezes. -- Best regards, Mit freundlichen Grüßen, Cristian Henzel -- 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/4dc1bf92.7050...@b3r3.info
Re: A concrete proposal for rolling implementation
Hiya, On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Yes, absolutely. This seems straightforward, elegant, and useful as it encourages maintainer to push their changes to the Debian archive and make them visible and testable to rolling users, even when unstable is de facto closed. It's an excellent idea. Some of the initial feedback that I've gotten about DEP-10 (in particular some brainstorming on IRC with Carsten Hey) is pointing at ideas along these lines, and I hope to flush them out in a bit more detail RSN. But I think it's particularly exciting that these two ideas (rolling, and dealing with freezes) might not conflict with each other, and perhaps complement one another. One issue that would need to be addressed with experimental is that opening a migration route anywhere out of experimental might come as an unpleasant surprise to some, since there's a standing expectation that it's a pseudo-suite where we can put stuff that we don't necessarily want to try out in unstable. Not an insurmountable problem (either we change that or introduce yet another psuedo-suite for this purpose), but worth note anyway. sean -- 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/20110504214045.ga4...@cobija.connexer.com
Re: A concrete proposal for rolling implementation
On Wed, May 4, 2011 at 6:40 PM, sean finney sean...@debian.org wrote: [...] On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. [...] One issue that would need to be addressed with experimental is that opening a migration route anywhere out of experimental might come as an unpleasant surprise to some, since there's a standing expectation that it's a pseudo-suite where we can put stuff that we don't necessarily want to try out in unstable. Not an insurmountable problem (either we change that or introduce yet another psuedo-suite for this purpose), but worth note anyway. Indeed. I guess we could specify a flag in this overrides file that says whether or not it's fine to fetch from experimental (defaulting to off). That way it would be up to the maintainer to specify that experimental is good and stable enough for rolling. I really like this new proposal, nice job. 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/banlktin4vnums0qbqe1ruvubkezyrhu...@mail.gmail.com
Re: A concrete proposal for rolling implementation
On Wed, May 04, 2011 at 10:48:46PM +0200, Carsten Hey wrote: * Pierre Habouzit [2011-05-04 22:23 +0200]: On Wed, May 04, 2011 at 10:19:45PM +0200, Josselin Mouette wrote: Le mercredi 04 mai 2011 à 22:12 +0200, Lucas Nussbaum a écrit : While I like the idea in general, I think that it should also be possible to upload packages directly to rolling (through rolling-proposed-updates). It will be useful in cases where neither the package in testing, not the package in unstable, can be used to fix a problem in rolling. Adding this possibility is opening Pandora’s box. Once you allow this, people start using packages that are neither in unstable nor in testing, and they don’t help us working on our packages at all. This also adds an extra burden on maintainers who want to use this feature. Could you please give a concrete example of where this would be needed? I think all existing cases should be covered by uploading directly to either t-p-u or unstable. Agreed, the entry point for rolling is clearly just unstable + a force hint. Why would you need to upload something to rolling that you couldn't make enter through unstable? If more new upstream versions are uploaded to unstable (because they are targeted at rolling), it raises the number of RC bugs needing to migrate to testing through t-p-u. How would you ensure that they get enough testing before entering testing? That's the point, you don't target rolling, your goal is still to make stuff migrate into testing, rolling is just the extra few packages testing needs to fix the most important breakages that happen (e.g. your PAM example, or large migrations where dependencies across libraries are too loose and break testing, Joss said it happens to gnome quite a lot e.g.). IOW to target rolling you target testing, IOW you help doing stable stuff, isn't that nice? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110505054655.ga26...@madism.org
Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 12:05:22AM +0300, Cristian Henzel wrote: What to do during freezes - I’m not sure we really need to do something different in times of freeze. Our time would be better spent by reducing the freeze time and making it more predictable; squeeze has been an awesome step in this direction. If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. Again, no disruption: people can keep on breaking some pieces of experimental, but if they want some other pieces to be useful for rolling users, they just need to be committed to more carefulness and to add them to the override file. I also find this a very good implementation, although I would like a 'true' rolling release, without any freezes at all. I'm not sure how much extra work it implies or how much sense it would make to have an exact clone of testing just without the freezes. Not a lot, I don't expect it larger than having to place a dozen hints usually, up to a small hundred during the peaks (100 is less than 1% of our source packages). Maintaining something like that isn't hard, it's already what the RM Team does to follow testing migrations, and if rolling is generated after testing is, the Rolling Team will benefit from the RT work so it's just an incremental effort. Nothing wasted. (And not wanting to finger point but I've read at least a certain RT Member saying that he would even consider help a Rolling Team as he's already doing that pinning on his workstation…) -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.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/20110505055010.gb26...@madism.org
