Re: Bits from the Release Team - Kicking off Wheezy
On 01/05/11 at 20:55 +0200, Pierre Habouzit wrote:
> On Sun, May 01, 2011 at 08:02:51PM +0200, Lucas Nussbaum wrote:
> > On 01/05/11 at 18:38 +0200, Pierre Habouzit wrote:
> > > You're saying:
> > >
> > > Problem:
> > > I acknowledge that people are not interested in stable releases
> > > enough and that the RT has to compensate all the time.
> > Those two statements are true:
> > - A subset of DDs care about doing stable releases. The rest of DDs
> > don't care.
> > - A subset of DDs care about doing 'rolling'. The rest of DDs don't
> > care.
> > The release team obviously cares about stable releases, and I mostly
> > read the individual positions of RT members in this thread as "if we do
> > 'rolling', it will be harder to do stable releases." Their position is
> > completely understandable. It's likely that doing 'rolling' will impact
> > stable releases in some ways. Some of the impact might be negative, some
> > might be positive.
> > But what we (the project) need to decide on is where we want to go.
> > After all, we could decide not to do stable releases, or to do them
> > every six months instead of every two years. The current choice of
> > doing stable releases every two years is there only because a large
> > subset of DDs care about doing that.
> The thing is, I think that rolling and testing are not compatible. So
> it seems unlikely to me that we can support both in Debian, especially
> not in the same namespace "testing" or "rolling".
> I don't want to lose stable releases, it's a disservice to our users.
> And if you try something like your plan B, you'll have two issues:
> (1) you'll split the userbase, some of the users will use rolling
> instead of testing, and during the freeze we're very interested
> about our users to test testing. It's actually the period where it
> matters the most.
> In the end you get less testing coverage, hence mathematically
> lessen the quality.
> (2) developers who already care little about stable releases will even
> care less because they will be able to do the work that they like
> (brining their software up to date, not really caring about stable),
> IOW it'll divert attention of the maintainers even more.
> Both will lead to a poorer quality of the stable release, and probably
> even longer freezes. Both are a disservice to the stable release, and to
> our users. And in the end both will put more pressure on the shoulders
> of the RT members that already don't scale.
The problems of Plan B have already been well explained in this thread.
And both (1) and (2) are (at least partially) addressed by Plans A and C.
> Of course rolling has some appeal, but it's just hype, and well,
> sometimes our users want silly things and we should know better than to
> indulge them.
> I agree that a 6 months freeze sucks because we miss a release for many
> upstreams (gnome, KDE, …), which makes packaging harder. But maybe we
> should focus on how to reduce the freeze period (which would in turn
> mean that we should have some study about why it's 6-months long instead
> of 3 like I'm sure it could be).
> I strongly believe that lessening the quality of the Debian stable
> release is harming Debian as a whole.
> And I know I'm rehashing things, but this will inevitably lead to more
> work for maintainers: supporting stable + testing means more work there
> is no way it will reduce the work. It's our scarce resource
> (developpers), so why don't we *first* focus on making packaging easier,
> leaner, simpler, and *then* see what we can do with all that new free
> time we just bought?
We have been trying to do stable releases while making packaging easier
for years now. If I follow your argument, why don't we stop making
stable releases for a while, and focus on making packaging easier?
[ Note that my position is based on the assumption that we have a
share of DDs interested in rolling similar to the share of DDs
interested in stable releases. Unfortunately, it's very difficult to
know where we stand regarding this. ]