On Sun, Dec 03, 2000 at 01:37:01PM +0000, Richard Taylor wrote:
> ..[snip].. what I would like to know is: Does anyone have any
> theories as to when the code freeze will start. I mean, getting a
> new realease out, with KDE 2 packaged and ready to go, plus XF86 4,
> would do a lot to restore the Debian Project in the eyes of
> joe-average linux-user.
Without beating a dead horse, I agree that Debian should go through
more frequent releases. Although branch freezes do involve a lot of
work, they seem to be the times when the largest amount of bugs are
fixed and the time when the developers are working together the
closest. Having a bit of time off between branch freezes are
important. Bug-fix parties can be quite exhausting. Still, two
releases a year is not too frequent to burn people out, yet frequent
enough to keep Debian's "stable" branch up to date.
Now, as I understand it, there's a couple on-going projects right now
that cover new installation software and procedures. There's another
project that is covering a new distribution system, I believe it is
referred to as a "pool". I don't know much about either of these, so
you'll have to browse the -devel archives to find out the details.
Sorry.
I have some interesting ideas on stable point releases of Debian and
package management that might be of interest, though. Currently we
use a versioned package system and an archive directory system to
track branches of software, stable, unstable, and (soon?working?)
testing. If we could tie in the lifecycle stages of the software
itself and the lifecycle stages of the packages into the package
management system, we could more dynamically manage the relationship
between our "stable point releases" and the packages themselves.
For example, let's say I want to install a base Debian server for the
purpose of hosting a PostgreSQL database. I want the most recent
stable package of the most recent stable version of PostgreSQL. I
also require the most recent stable packages of the supporting stable
software, however, I know that xinetd has some major bug fixes in it's
"unstable" release. I'll accept a stable package for the unstable
version of xinetd.
I could enter these package requirements in a package list-maker. I
could then choose to install or interactively approve, disapprove,
upgrade or downgrade individual packages until I have a list that I'm
happy with. Throw the list into dpkg --set-selections, fire off
apt-get dselect-upgrade and enjoy a cup of coffee as my system gets
built.
Now, a lot of this functionality is available, but the integration of
individual package and software lifecycle attributes would greatly
increase the flexibility and useability of the packaging system.
Disclaimer: I haven't been keeping up with -devel threads lately, so
if I'm rehashing someone elses ideas, I apologize for the redundancy.
--
Chad "^chewie, gunnarr" Walstrom <chewie@wookimus.net>
http://www.wookimus.net/
Attachment:
pgpelg28w6Djb.pgp
Description: PGP signature