Re: 1. RFD: Reorganization of the Debian Project

[Bdale Garbee <bdale@gag.com>]

In article <32A0D333.40B4AEBF@megabaud.fi> you wrote:
: 
: Well, even if this can appear foolish, I suggest that Debian should give
: up releasing distributions.
: 

Fascinating.  I'd like to see this idea get some serious discussion, and not
just be dismissed out of hand.  We clearly haven't gotten the release thing
figured out adequately, yet... and it's an angst-generator every time we try
to do a release.  Maybe we can fix that, maybe we can't.

I've always believed that one of the most significant features of Debian is
that the dependency management system allows for incremental upgrades.  I've 
never seen much point in "releases" except to provide pressing points for 
CD-ROM distribution.  We shouldn't belittle that as many folks want to install
from cheap CD's, but perhaps the release process could become less an issue
for developers and more an issue for distributors?

The idea of a developer like me creating a pseudo-package that depends on all
the packages I care about at revisions that I believe all work well together,
and making that available as a "distribution/release" for others to install 
is a really intriguing idea, and might be really useful locally.  Without a
change in the way we handle package versions, in particular how we allow the
older version of packages that are upgraded to vaporize instantly, I don't see
how this can be really practical, though.  I thought about this a lot when I
was managing the archive, and I never came up with a scheme that I liked and
that ftpd/mirror could handle rationally...

: We should add to dselect[4] the possibility to select a predefined list
: of chooses, and then leave to each distributor the responsibility to
: create/organize his list(s). We could supply some installation-lists in
: the ftp site, as examples.

A variant on a good idea which has already received some discussion...  I hope
the work to add a "pick one of these bundles of packages if you wish" layer to
dselect continues forward regardless of how we handle releases.

: [3] As someone else pointed out, unstable in the last months seemed to
: be more stable (and less buggy) than stable-fixed.

:-)  True, but you have to be careful about generalizing this.

There are, and have always been, some issues with packages in the unstable
tree at any given moment, most often regarding dependencies that are broken
for short periods when something is changing.  The current/recent issues with 
X are a good example, as were the dependency issues surrounding the switch to
ELF/libc5.  Yes, these were "rare, big deals", but there have been many other
examples less onerous to handle.  

This has meant that once in a while, for a week or two, the unstable tree was
a pretty difficult/dangerous thing to try and install as a distribution.  On
the other hand, these problems tend to get corrected pretty quickly.  As a 
developer, I'm sufficiently comfortable forcing a dependency issue once in a 
while to get the behaviours I want from "unstable" that I wouldn't really 
consider living with "stable".  Perhaps that attitude doesn't generalize 
well, though?

Maybe there's some sort of middle ground...  A faster, and more predictable,
release schedule would be good since it would keep the "value" discrepancies 
between stable and unstable down to a more manageable level...

Bdale


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com