[cut-team] Ideas for the rolling release

[Reinhard Tartler]

On Mon, Aug 16, 2010 at 13:38:38 (CEST), Lucas Nussbaum wrote:

> On 16/08/10 at 12:25 +0200, Reinhard Tartler wrote:
>> On Mon, Aug 16, 2010 at 11:44:30 (CEST), Lucas Nussbaum wrote:
>> > 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.
>
> I don't understand why you think that any of the above would be harmful
> for testing. Could you explain?

I've tried to elaborate on that in a seperate mail:
http://lists.alioth.debian.org/pipermail/cut-team/2010-August/000022.html

If you have specific questions, could you perhaps ask them as reply to
that mail directly? I'd like to avoid cluttering the discussion too
much.

> Also, I don't think that we need to determine precise criterias or
> policies for when we will fast-track migrations or when to do direct
> uploads to rolling through rolling-proposed-updates. As long as we agree
> on the goal we have for rolling, it should be easy for the team in
> charge to determine when/how to do fast-tracking on a case-by-case basis.

Here I disagree and think that a more clear understanding here is
essential. I fear that espc. a too lax policy fast tracking the testing
migration of packages can have a bad impact on the perception of the
quality of the 'testing' distribution.

Or let me put it the other way: I don't think that we will get much
support from the (current) release team if we propose something that
degrades the current testing distribution.

>> 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'?
>
> It helps to maintain installability in rolling (though it's true that it
> can be achieved by other means, by keeping old Arch:all packages around
> like in unstable).

Probably. I'm not against such a staging suite, I just don't think that
this is a key question right now. Let's focus on more important
questions at this point.

>> 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'.
>
> I don't see how this would be significantly different from doing them in
> unstable?

Because uploading unstable is likely to make ongoing transitions more
difficult. Please reread my previous mail (link above).

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