Re: Debian: abandon ship?
David Z Maze <dmaze@debian.org> writes:
> Brian Nelson <nelson@bignachos.com> writes:
>> I agree. I think stable should be able to get more fixes and updates
>> than just security fixes. It's well known that much of the software in
>> stable is quite buggy and years behind the upstream source (Mozilla M18,
>> for example) but cannot be fixed until a security hole is found in that
>> software. I think regular points releases, every month or two,
>> containing new software and updates to older software, would be great.
>> No major changes would be permitted of course, but there's no reason
>> most desktop software couldn't be updated in stable.
>
> This came up on debian-devel not too long ago. Someone proposed a
> "point release" to woody that would have gcc-3.1, GNOME 2.0, new KDE,
> and "no major changes to the distribution" -- even though this would
> require recompiling everything with a relatively untested compiler,
> and presenting a relatively untested desktop environment to new
> users. Sure, it's good PR to have a "release" with ooh-new-and-shiny
> components, but it's less clear that it'll actually *work*, which
> should be the point.
I saw that post, but I didn't think it was well thought-out.
> (There's also the problem that each of the developers has their own
> personal pet packages that they'd really like to make the "point
> release", but it can't happen for everyone's packages, and someone
> needs to make the decision. Hypothetically, to pick one of my
> packages, there could be a new lm-sensors release. I say, "it's
> important because it supports 17 new temperature sensor chips!" But,
> it includes libsensors2, which replaces libsensors1 and affects three
> or four other packages; is it a "major change" or not?)
I would define a major change to be something like the jump to gcc-3.1
or a libc6 version change, ie. something the affects nearly everything
in the archive. I wouldn't consider a library that affects 3 or 4 other
packages a major change.
Why not just have point releases work in a similar manner to the
testing->stable procedure, but on a smaller scale? For example, a new
testing pool based on the stable pool (called proposed-updates or
whatever) could be opened for a month or so, during which updates and
new packages could be uploaded. After a month it could be frozen, and
then for the next 2 months bugs could be worked out. If something like
the upgrade to libsensors2 broke too many things, it could be backed
out.
Then, after 3 months (theoretically, of course), a point release with
newer packages could be available.
--
Brian Nelson <nelson@bignachos.com>
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: