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