[cut-team] Ideas for the rolling release

[Lucas Nussbaum]

On 17/08/10 at 10:19 +0200, Reinhard Tartler wrote:
> On Tue, Aug 17, 2010 at 09:23:45 (CEST), Lucas Nussbaum wrote:
> > 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.
> 
> This is not exactly accurate. My concern is that maintainers will make
> uncoordinated uploads of packages to unstable that a) interfere with
> ongoing transitions and/or b) are not targeted for the next stable
> release. I'm not talking about packages of less quality; packages that
> are actually not mature enough [c)] would also be a concern, but looking
> at the past, this point has not been the biggest issue in the past
> AFAIUI.
> 
> The bigger problem is rather that in many cases maintainers prefer to
> have newer (and often "better") upstream releases in unstable, which is
> often arguably correct. However, also very often they leave the actual
> integration into the rest of the Debian system (this is what we actually
> want to achieve with the testing migration on a very high level) to
> their fellow developers, most prominently the release team.
> 
> Let me give you an example: I would love to have uploaded FFmpeg 0.6 to
> testing before the freeze, so that our multimedia applications like
> mplayer, vlc, etc. can playback VP8 files. 0.6 has been released this
> April, and many upstream developers are actually surprised that it won't
> make it to for squeeze. However, the release team has let me know that
> there are already ongoing transitions and asked me to refrain from that,
> and I respect that. And I know that there is a lot of other pending
> transitions that didn't make it, see e.g. perl, xulrunner and
> whatnot. All packages that are of *higher* quality, but still unsuitable
> for unstable.
> 
> > I don't think that this is a valid concern.
> 
> With my clarification above, do you still consider it invalid?

Yes: those are already current problems, but I don't see why they would
be worsened by rolling (or a widely-used testing).

> > 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.
> 
> Yes, I agree to that for the 'rolling' idea, which is clearly not the
> 'snapshot testing' idea.
> 
> Do you propose to not snapshot testing at all, but go with 'rolling'
> only?

I propose to snapshot testing (or rolling) for installation, but then
force users to upgrade to rolling (or testing). (to clarify: my "vote"
on the different alternatives would be 1) rolling 2) improve testing 3)
NOTA 4) only snapshots).

> >> 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'm talking about endorsement.
> 
> > But let's not talk too much for the release team. Ideally a team member
> > would jump in this thread.
> 
> The facts that a) none of them has even bothered to file a single post
> to this list and b) they have been very quiet during the cut talk makes
> me suspect that they are not really happy about the discussion so far at
> all.

Really, let's not talk too much for the release team. I had dinner with
members of the release team after the CUT BOF, and what they said back
then is not well reflected at all by your comments. Also note that only
11 different developers have participated on this list so far. I see
this discussion as "let's see what the different solutions encompass,
then write a summary for the wider audience".

L.