Re: A concrete proposal for rolling implementation
On Thu, May 05, 2011 at 06:51:35PM +0200, Goswin von Brederlow wrote:
> Pierre Habouzit <email@example.com> 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