[cut-team] Ideas for the rolling release

[Reinhard Tartler]

On Mon, Aug 16, 2010 at 11:44:30 (CEST), Lucas Nussbaum wrote:

> On 16/08/10 at 11:22 +0200, Reinhard Tartler wrote:
>> On Mon, Aug 16, 2010 at 11:08:12 (CEST), Lucas Nussbaum wrote:
>> 
>> > On 15/08/10 at 19:04 -0500, Anthony Towns wrote:
>> >> But maybe there's a clearer explanation of what "rolling" is meant to
>> >> achieve that would completely make sense of everything for me.
>> >
>> > "rolling" is a new suite, similar to testing, that aims at providing
>> > something constantly usable for end users.
>> 
>> How are packages in this scenario updated in "rolling"? By migration
>> from another suite like 'unstable' or 'experimental'? Or by direct
>> maintainer uploads? Please elaborate.
>
> According to Joerg Jaspert's email[0], we only need to supply ftpmasters
> with a file that lists which packages should go into that suite. How we
> generate this file is our problem.
>
> The way I see it, there are two different cases:
> - when testing is not frozen, we could base rolling on testing, with
>   additional overrides (secured by installability checks). I'm not sure
>   if the right way to do that is to run our own britney or just to hack
>   a simple script.

So you do want to allow fast-tracking testing migration? What is your
criteria for allowing this? As said, I'm concerned that if we are too
lax here, we encourage people to make uploads that harm testing.

> - when testing is frozen, we would have to run our own britney instance,
>   managing migrations similarly to the testing britney.

The same concern applies here, but even mroe.

> In both cases, through manual hinting, we would pick up packages in
> unstable (and experimental if possible, that needs to be checked with
> ftpmasters, probably). So the normal path would be for maintainers to
> upload to unstable as usual, and the packages would get to rolling by
> migration.

As said, I'm unhappy with that idea, unless you can argue why this won't
impact 'testing' in a bad way.

> Additionally, it would be great if we could be able to do direct uploads
> to rolling (through a rolling-proposed-updates suite). That could allow
> to limit the impact of transitions by uploading packages built against
> packages already in rolling.

This requires again a new policy for migration of packages from
'rolling-proposed-updates' to 'rolling'.

For the sake of simplicity, I think we don't need
'rolling-proposed-updates' in the beginning. Debian manages to do
transitions in unstable directly as well, so why shouldn't this be
possible with 'rolling'?

What IMO would be really helpful however, would be the ability to do
binNMUs in experimental. AFAIU from Phillip (Kern), our infrastructure
is almost ready to support this, and only needs some minor bugs to be
ironed out. This way we could do library transitions properly in
experimental and copy them to 'rolling'.

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