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 ··O madco...@debian.org OOO http://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