Re: Bits from the Release Team - Kicking off Wheezy
On 02/05/11 at 08:19 +0200, Pierre Habouzit wrote:
> On Mon, May 02, 2011 at 12:10:42AM +0200, Lucas Nussbaum wrote:
> > On 01/05/11 at 23:46 +0200, Pierre Habouzit wrote:
> > > > Benefits for Debian:
> > > > - attract users who think that testing is only a development branch, and
> > > > want newer software than what one finds in stable. Those users are
> > > > likely to be rather advanced users (developers, free software
> > > > contributors), thus interesting to work with. Some of them could
> > > > become Debian contributors. And even if they don't, more users of
> > > > testing/rolling means more testers of the next stable release
> > > > [remember how the bug reporting rate of Ubuntu is higher than
> > > > Debian's -- some areas of Debian could use more testers].
> > >
> > >
> > > I think those can use unstable,
> >
> > But unstable is a development branch not targeted at being used by
> > 'standard' users.
>
> Well, assuming it's the case, what is missing in order to be usable by
> "mere" users?
IMHO, what is missing for unstable to be usable for mere users is what
the unstable->testing migrations provides: a maturation period that
allows severe bugs to be catched before they hit most users.
> Also note that testing as is has not enough security support, and read
> Carsten very good example of the PAM issues. How would CUT or rolling
> address those?
The PAM issue outlines how splitting the users and developers between
two branches (unstable and testing post-freeze in the PAM case) causes
problems.
However, we can make rolling without splitting the users and developers
between two branches during the whole freeze.
'rolling' is a statement by the project that we consider 'testing'
(renamed to 'rolling') to be usable by 'mere' users who want more
up-to-date software than what they find in our stable releases, or in
our derivatives.
'rolling' would be very similar to what we have in 'testing'. Yes, users
can already use testing or unstable, but then they have the reasonable
feeling that they are using a development branch and not something that
the project considers a 'product'.
Yes, it's mostly "PR bullshit", and I don't expect it to significantly
change Debian development processes. However, communication is necessary
if we want to attract new users. What might change is more attention
from developers to what happens in testing/rolling, which is probably a
good thing since a better testing/rolling makes it easier to create
stable releases from it.
Then, there's the discussion of what to do during freezes. There are
several options:
[A] we could decide not to do anything special: just freeze rolling for
~6 months, as we used to freeze testing. That might bore people who
like the constant flux of new upstream releases, but if we decide
that it's the only way to ensure high-quality stable releases, so be
it.
[B] we could decide to fork a 'frozen' branch when we freeze, and
continue to manage rolling using migrations from unstable. This clearly
makes it harder to create stable releases, since it splits the users
and developers base between two branches (less users => less bug
reports ; less developers => less bug fixing). It doesn't sound
reasonable to fork a 'frozen' branch, and then try to release it for
6 months.
[C] we could compromise. We could freeze rolling for 3 months, so that
most of the stabilization work occurs with a single active branch,
and then, for the final release preparation, fork 'frozen' off
'rolling', and unfreeze 'rolling'.
> I've used testing in the past, in the sarge era. I had to constantly
> install packages from unstable for it to work, and the result was a
> nightmare of apt-get installability. I've not used testing since, so
> /maybe/ it's better nowadays, I'd very much like to have some feedback
> from real and recent testing users if there are any, but if I trust my
> past experience, the gap to make testing usable is significant. So maybe
> making unstable usable isn't *that* much more significant, and is
> definitely more compatible with our current workflow.
I'm using testing, and don't share your views. But YMMV. It's also
possible that the introduction of 'rolling' will result in slight
changes to the way we manage testing. For example, the 2/5/10 delays for
testing migrations are mostly arbitrary. It could make sense to refine
them on a case-by-case basis. The goal of those changes would be to
increase the usability of testing. I don't see any wrong with that.
> > > and if they use rolling, I think I
> > > already "proved" or at least explained why those don't contribute to the
> > > stable in being, but rather the N+1 one.
> >
> > I think that you are mixing two things here:
> > 1) whether we want to turn testing into a rolling release
> > 2) what do do with the 'rolling' suite during freeze (fork a 'frozen'
> > branch at the beginning of the freeze ? freeze rolling ? start by
> > freezing rolling, then after a few months, fork 'frozen' and unfreeze
> > 'rolling'?)
>
> I don't mix things. (1) is: no we don't want to turn testing into
> rolling because you need to freeze to release.
Unless we do [A] or [C].
> If rolling appears it
> must be a second suite. So yes (2) is a question. But frankly, if the
> answer of (2) is we don't do rolling during freezes I don't understand
> the point of the whole discussion, so I assumed that the answer was "yes
> we do rolling all the time".
>
> Actually, the more I read, I think that:
> - nobody knows why we want rolling or CUT (though I've read cut.d.net
> since, and to me it looks like a glorified snapshot of testing + d-i
> + cd images + all that makes a stable, which basically is just
> fine by me);
rolling != CUT
<[🔎] 20110501204107.GA19688@upsilon.cc>
<[🔎] 20110501213947.GA4076@xanadu.blop.info>
> - nobody knows what rolling *exactly* is, what the plan is.
I've tried to describe how I see rolling above. Feel free to ask
questions.
> We know
> the hype and that "Debian would very much like to support it", but
> what's the formal definition, what does it encompass, what does it
> mean, what's the recommended implementation?
Isn't it expected that we discuss that together?
Anyway, [C] above would be *my* preferred implementation.
> > > > - give back to the free software world by providing a platform where new
> > > > upstream releases would quickly be available to users. Since users
> > > > would be able to test new upstream releases earlier, they would be
> > > > able to provide feedback to upstream devs earlier, contributing to a
> > > > shorter feedback loop.
> > >
> > > Why doesn't unstable fit that?
> >
> > Because unstable is a development branch not targeted at being used by
> > 'standard' users.
>
> Testing is a release tool not targeted at being used at all. So to me
> testing and unstable are both more or less at the same point, with
> unstable having the clear advantaged to be targeted at _some_ users. Why
> is that so much easier to make testing usable with respect to making
> unstable audience broader?
Debian stable releases, Ubuntu releases, Debian testing and
Debian unstable are all different instances of compromises between
up-to-dateness, quality, support, etc.
Depending on the target usage, users will choose one or the other. It
seems that there's more demand and desire for something close to what
testing provides, than for something close to what unstable provides.
We could also see how we could 'import' some of unstable 'features' to
testing.
- Lucas
Reply to: