Re: Bits from the Release Team - Kicking off Wheezy
* Pierre Habouzit [2011-05-02 08:08 +0200]:
> On Mon, May 02, 2011 at 01:56:14AM +0200, Carsten Hey wrote:
> > * Pierre Habouzit [2011-05-01 23:17 +0200]:
> > > The problem is, you need to entry points, one for testing as we know it,
> > > one for rolling.
> > Actually, we need two entry points each, a default one and an
> > exceptional one. The latter ideally requires a special permission from
> > a release team before an upload. For testing these are unstable and
> > testing-proposed-updates.
> Urgh. Sounds a lot.
1st phase: - add unstable-proposed-updates
2nd phase: - create symlink rolling, pointing to testing
- create symlink rolling-proposed-updates, pointing to
3rd phase: - freeze testing
- make rolling and rolling-proposed-updates real suites
If rolling is supposed to be a subset of testing, making rolling and
rolling-proposed-updates real suites would need to happen earlier.
This completely ignores what seems to be the original motivation for
CUT. Maybe there is a different solution to provide what d-i alpha and
beta releases need or reduce what they need.
> > > If you use t-p-u for testing and unstable for rolling, or unstable for
> > > testing and rolling-updates for rolling is just bikeshedding. The result
> > > is some of the users will use unstable and help testing, the other sort
> > > will run rolling-updates or rolling.
> > >
> > > So basically you split our users in two non overlapping sets, meaning
> > > that you divide coverage and tests.
> > The result of this bikeshedding has an influence on how big these sets
> > are.
> I agree, the original sizes, I expect them to converge more or less to
> the same end result, which is what is important on the long term.
Many people just choose what's default. d-i installing testing instead
of rolling by default would raise the number of the testing set.
Requiring users of unstable + -updates to add -updates manually to the
sources.list would in my opinion decrease this set of people.
> > > I'm interested about *why* they want it, not the mere fact that they
> > > do. Because when you know why they want it, maybe there will be better
> > > answers that don't make releasing even more brittle and burn even more
> > > people out.
> > I guess it's mainly about new upstream versions (firefox, chromium,
> > gnome and so on) they read in the news about, saw on other computers or
> > really contain features useful for the users.
> > Moving backports.org to backports.debian.org and enabling automatic
> > upgrades by default are steps in the right direction to address this
> > (except for desktop environments).
backports.debian.org does not fit here, it makes stable more attractive
for users that would otherwise run testing.
Making testing more attractive for users that would otherwise run
rolling could be done with "semi-official PPAs".