[cut-team] Ideas for the rolling release

[Lucas Nussbaum]

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.
- when testing is frozen, we would have to run our own britney instance,
  managing migrations similarly to the testing britney.
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.

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.

[0] http://lists.debian.org/debian-release/2010/08/msg00011.html

- Lucas