[cut-team] Ideas for the rolling release

[Lucas Nussbaum]

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?

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.

> 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).

> 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?

- Lucas