[cut-team] Ideas for the rolling release

[Lucas Nussbaum]

On 16/08/10 at 15:28 +0200, Reinhard Tartler wrote:
> 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:
> >> > 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

Re-reading your mail, I think that your main concern with 'rolling' is
(rephrasing) that maintainers will make uncoordinated uploads of
packages of less quality to unstable, thus making it harder to get
transitions done (=> more work for release team), and lowering the
quality of testing since those low-quality packages will end up in
testing at some point.

I don't think that this is a valid concern.
The goal of rolling is not to provide something with all the latest
crack, but to provide something constantly usable for end users.
I don't see the cursor being positionned much differently that it is
today for testing when it is not frozen (users are happy about that,
why change it?), with a few differences like trying to get some
important (and good quality!) packages earlier in rolling.
Clearly, the goal isn't to provide an aggregation of half-broken beta
software.

Also, rolling is likely to be very similar to testing. Bugs filed by
rolling users are likely to be applicable to the testing version. And
more users of rolling or testing is a good thing, since it allows to
find more bugs that will be fixed in stable.

Finally, on transitions, we already have a technical solution that
blocks some packages from being uploaded during transitions. And we also
have the social solution of warning developers that they should not
upload. I don't see why developers would become crazy and volunteerly
break this rule just to get newer packages in unstable and rolling.

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

I'm not sure of what kind of support you are talking about.
I think that the release team has enough on its plate now with testing,
and I wouldn't expect it to say "oh, cool, we have too much free time,
let's work on rolling too". Clearly, we would need a new set of
volunteers to manage a "rolling team", that would work in cooperation
with the release team.
But let's not talk too much for the release team. Ideally a team member
would jump in this thread.

- Lucas