Re: Bits from the Release Team - Kicking off Wheezy
* Pierre Habouzit [2011-05-01 23:17 +0200]:
> On Sun, May 01, 2011 at 11:07:48PM +0200, Raphael Hertzog wrote:
> > On Sun, 01 May 2011, Carsten Hey wrote:
> > > > Testing, OTOH, is really unique in that respect, with its mixture of
> > > > fresh software and quarantine period.
> > >
> > > A 'frozen' requiring most updates to go through *-proposed-updates would
> > > make this quarantine period a lot less useful, and it would make
> > > circumstances like the one described above a lot more probable.
> > >
> > > One cause that testing-proposed-updates is not more widely used is that
> > > there is no good non-altruistic reason for a user to do so. More
> > > up-to-date packages are available in unstable and more tested packages
> > > are available in testing.
> >
> > There's a good reason to use testing-proposed-updates during freeze, it
> > fixes security and release critical bugs that are present in testing!
I should have highlighted the word "most". With the present scheme,
updates to testing that need to go through t-p-u are exceptions.
> > So if we tell users to use this repository, we're going to have
> > some users (I upgrade my servers to testing during the freeze and I
> > would enable it if it was generally advised for beta-testers).
The libpam-mount example was not a 100% fit because it went through
testing-security and not through t-p-a. The segfaulting package
migrated to testing on the 28th of November 2008. Just five months
earlier the "Testing Security team" announced[1] on d-d-a that they
provide nearly full security support (the kernel was missing at this
time).
I doubt that generally advising to add t-p-a would significantly work
out better than the testing-security announcement.
[1] http://lists.debian.org/debian-devel-announce/2008/06/msg00006.html
> > But yes there might be some unrelated regressions from time to time.
> > There's a reason why it's not labeled "stable" yet.
Not being able to login is more than just a unrelated regression.
Quote from #507199:
| for users with encrypted volumes there is NO LOGIN POSSIBLE! it
| renders my system unusable. without the crypted volumes, there is no
| need to login at all... ( now i am glad that root does not have any
| encrypted volumes! )
|
| login is only possible, if all crypted volumes for the user are
| commented out.
With sudo instead of a "real" root account he would have needed to start
a rescue system to be able to login again.
> 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.
> 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.
> How come is that in the distribution interest?! I think it's not,
> I think it's resource squandering.
I'm undecided if rolling in general is a good idea, but I think
unstable-proposed-updates (the name does not matter, but the concept)
would be a good thing, with or without rolling. This possible
non-selfcontaining suite just happens to fit rather good into the
rolling concept. I also think using t-p-u per default to feed testing
would significantly lower the quality of a frozen testing (with an other
color and thus different sized sets, it should in my opinion work
though).
> 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.
Regards
Carsten
Reply to: