[cut-team] cut-rolling, cut-rolling-*

[Reinhard Tartler]

On Tue, Aug 17, 2010 at 11:41:42 (CEST), Lucas Nussbaum wrote:

> On 16/08/10 at 11:14 +0200, Reinhard Tartler wrote:
>> Idea: have both 'cut' and 'cut-rolling' suites
>> 
>>   - the 'cut' suite is strictly following testing, similar to how
>>     testing follows unstable. This means that normally, cuts are kept in
>>     sync with testing, but during freezes, migrations from 'testing' to
>>     'cut' are kept manually. This way we ensure that the current RT
>>     does most of the work for 'cut' during their regular work on 'testing'.
>
> So what you call 'cut' is what I call 'rolling', basically. While what
> I call 'cut' is the actual snapshot (frozen except for security updates)
> of testing (It's likely that there wouldn't be a 'cut' suite, but
> several -- one per snapshot).

oh I see, this means we really need to clarify the proposed update policies.

>>   - 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:
>> 
>>      1. since it is based on 'cuts', we get the our well-known testing QA
>>         that has proven to work pretty well
>>      2. for add-on packages, the cut team reviews backports nominations
>>         by individual package maintainers.
>> 
>> I imagine that cut-rolling has most relevance when we freeze for a
>> release, like right now.  During regular development with mostly
>> unsupervised transitions, cut-rolling is likely to ship less backports.
>
> So this would be a suite for which APT pinning would not install
> packages by default, but from which packages would be available for
> users that want them?

This is an option I didn't think of. Probably a valid idea, but I
imagined that people who choose to enable that suite would get all
updates by default. This question could be implemented in the installer.

> I don't really see how this would work without much human intervention,
> since you would need to backport other packages together with a given
> package.

Well, by configuring buildds to build packages in chroots with 'rolling'
enabled, the actual building could be done fully automatic.

For the technical part of introducing a new package in such a suite, I
think we could go with backports implemented as source-only copies of
the source suite (experimental/unstable/whatever) (obviously not for
direct uploads, if we permit them, but that's a seperate discussion)

> And the fact that a package builds fine doesn't mean that it
> works. Who would test the backports before they land in cut-rolling ?

The same people that test packages in unstable: we developers and our
users. In contrast to plain unstable, the packages already have seen
some testing in unstable.

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