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
Reply to: