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
··O madcoder@debian.org
OOO http://www.madism.org
Reply to: