[cut-team] Ideas for the rolling release

[Reinhard Tartler]

On Mon, Aug 16, 2010 at 16:18:46 (CEST), Raphael Hertzog wrote:

>>   - the 'cut-rolling' suite contains (semi- ?) automated backports from
>>     *experimental* (not testing). Direct uploads to 'cut-rolling' are not
>>     permitted. This should encourage people that care for 'cuts' to care
>>     for testing at the same time, even if that only means to not disturb
>>     the 'regular' testing migration. QA for 'cut-rolling' is therefore
>>     ensured on two levels:
>
> I think using experimental here is only a bad way to avoid maintainer
> uploading stuff to sid that is targetted to rolling without consideration of
> testing.
>
> I don't find this a good design.

OK. But could you please elaborate why you don't think experimental
appropriate for that?

Uploading a package to unstable that is not targeted for testing means
this package can no longer be updated via unstable but needs uploads via
t-p-u. The release team asks package maintainers since a couple of
releases to avoid this. It seems to me that you disagree with the RT
here; could you please elaborate on that?

OTOH, I suspect that...:

>
>> I don't think that toolchain packages (like gcc-defaults, binutils,
>> debhelper, cdbs, etc.) are well suited for the purpose of 'cut-rolling'.
>
> It depends. The idea of rolling is also to alway allow pushing the latest
> stable version out to users even during a freeze.
>
> For packages like dpkg it means we can continue pushing out new features
> during the freeze and really maintain two branches in parallel.
>
> But this requires that testing stops relying on unstable during the
> freeze to get fixes.

...you want to get rid of this workflow.

It seem to me that we disagree on this point: Should uploads to unstable
always be targeted for the next release, even during freeze times? My
answer is clearly 'yes'.

What's the problem with uploading new features of dpkg to experimental
ask users to install it on their systems that follow 'cut-rolling'? To
me installing it by default will get you of course a much bigger
testbed, but also sets users a much bigger risk of breaking their
system. And the whole project was coined 'constantly *usable* testing'
after all, no?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4