[cut-team] Ideas for the rolling release

[Reinhard Tartler]

On Tue, Aug 17, 2010 at 09:23:45 (CEST), Lucas Nussbaum wrote:

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

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?

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

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

If it is so similar, why do we need it, or with AJ's words, how do you
measure that it's 'better' than testing?

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

I'd also like to see such upload blocks employed more often, but it
AFAIUI, the release team is concerned to not annoy maintainers with
these blocks too hard. And I've given some IMO valid example motivations
to break these rules further above.

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

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