Re: 1. RFD: Reorganization of the Debian Project

[Dale Scheetz <dwarf@polaris.net>]

On Sat, 30 Nov 1996, Bdale Garbee wrote:

> 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?

Releases are very irrelivant to most developers and to any hackers who
understand their system. Releases are slightly useful to CD distributors
because they allow an understandable label to be attached to the CD. No,
releases are only of interest to end-users of modest technical skill. It
is for these folks that we try to produce a "stable collection of
packages" that will "all" install without taxing the installers skills.

> 
> 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.
> 
This capability was available in 1.1 as a perl script (UpGrade) and is
currently available from me as DoList (still a script) along with a base
list and devel list. I have not packaged this yet (and probably will not),
but, like last release, I can put it into the archive wherever
appropriate.
My plans are, to make this into a C program (so the perl dependence goes
away), but I want to try and build a library of dpkg primatives before I
do this (or trick someone else into doing it). At this point I would be
ready to package it and add it to the distribution proper, or fold it into
the dpkg package.

> : [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?

The above two paragraphs are an adequate set of reasons to HAVE a release.

> 
> 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...
> 
One of the things that would help this greatly would be to actually have a
release schedule. We got closer this time than last, but making an action
list 4 weeks before you "expect" to release, is not a schedule. 
On the day we release 1.2 we should have a schedule, on paper, for 1.3.
That schedule should include:

Target goals for the release. 

Required items should have critical paths defined so that all developers
involved in the issue know what is required of them, and when they need to
complete their tasks.

Target dates for each of the stages the release will go through, 
including:

		Date of code freeze.
		Date for beginning internal Beta test.
		Date for beginning external Beta test.
		Alpha pre-release date (possibly optional)
		Date for Public Release.

If we all know where we are going, and when we expect to get there, the
likelyhood of success will be greatly enhanced.

I would like to take this opportunity to thank Brian W. for his valiant
effort at managing this release. I know we have heard all the "reasons"
for his "failure". I would like to add my insite to what has already been
said. The "real" reason this attempt ended in failure was due to lack of
time. You can't start scheduling a release two weeks to a month after the
expected release date and expect to "have the time" to make reasonable
decissions about what should and should not be fixed by the release date.

Thanks for your attention,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  dwarf@polaris.net

------------ If you don't see what you want, just ask --------------


--
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