Re: Debian: abandon ship?
Tom Cook <tom.cook@adelaide.edu.au> writes:
> On 0, Brian Nelson <nelson@bignachos.com> wrote:
>> 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.
>
> How will that be better and suffer from less release schedule problems
> than testing? As soon as the proposed-updates pool is opened, every
> developer will want his/her package in there, because it is, of course,
> important. Then testing will become neglected, and every new package
> will just go into proposed-updates, which then doesn't get released
> because we're waiting on bug fixes, and security infrastructure...
> what's the difference?
Basically, there would be two package development trees:
unstable/testing and stable/stable-updates. Unstable/testing would be
for development for the next major Debian release (as in woody, potato,
slink...) with stuff compiled with gcc-3.1, etc. Stable/stable-updates
would be analogous to the rX releases, as in 2.2r5, but with more
changes than we currently see. It would be similar to the potato +
unofficial updates (2.4 kernel, XF4.1, etc.) situation we have now, but
with those updates actually being supported.
There's no reason testing would be neglected. It would contain the
latest software and would be the most interesting distribution for a
developer. The stable-updates basically be back-ports of testing
packages, when they could be back-ported. Over time, the stable tree
would become stale and harder to update as it would become harder to add
updates without too much breakage. According to my original proposal,
stable-updates would only be unfrozen for one month out of every three,
so every package couldn't be added there all the time.
Developers would be encouraged to show some restrain and not make huge
updates to packages in stable-updates. Furthermore, if packages in
stable-updates were too buggy for release, they would simply be removed
by the release manager and the currently stable version would remain
unchanged.
The security infrastructure would never have to change because no new
arches would be added to a point release. Since a major stable release
would never be made without an adequate security infrastructure already
in place, this is a non-issue.
--
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: