Re: Bits from the Release Team - Kicking off Wheezy
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.
> > 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. And
clearly, we have to make "rolling" create its feeding routes, not steal
testing ones, that's kind of obvious to me :)
> > 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). Supporting or even recommending to
> use all packages from b.d.o to make it feel like a rolling release would
> be nearly the opposite of how it is intended to be used now and I don't
> think it would make those users really more happy. So all in all, the
> scheme used to manage b.d.o seems to lack improvement potential from
> a users point of view :)
> An other way to use newer upstream versions is via chroots. With faster
> internet connections, larger hard disks, faster CPUs and a smaller size
> of a minimal Debian chroot, using a chroot to run a single application
> could become more worthwhile. With a frontend to configure such things,
> it could be used be end users in future.
Yes, I'd very much like to see this kind of routes explored before we
rework all the suites in Debian…
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Reply to: