Re: Modest proposal for successful releases

["Brian C. White" <bcwhite@verisim.com>]

> One thing that the discussions about releases has made very clear is that
> it is more than a little important that be provide releases that can be
> installed without the uglyness of mismatched dependencies that cause
> dselect to fail misserably. That it is detrimental to Debians public
> perception to provide a release with broken packages. And, on this last
> release, that the release gets made without adequate testing.

Agreed.


> 1. The release date is set before development begins.

This is always a problem.  However, because Debian is not a developed
piece of software, but rather a collection of developed software, I
don't see fixed release dates as a problem that cannot be overcome.

> 2. Development continues at a rapid pace, right up to the release date.

Definitely.  The "frozen" was supposed to be just that, but it didn't
work out that way.  Since things are frozen 1 month before intended
release, I think that is adequate time (1/3 of the total release time).
We just have to make sure that _nothing_ that is not a bug-fix goes
in there.  It's real easy to say, "Oh, just one minor change.  What
could possible go wrong?"  I did it myself with mime-support and I was
the one managing the distribution at that time.

We also have to ensure that anything that does was built on a frozen system.
Because the standard way of building a package determines what shared libs
are being used, it is very easy to get a dependancy on package that doesn't
exist except in "unstable".  I can't think of a way of restricting the
building of package to avoid this, so the only thing I can think of is to
have the FTP install scripts verify all dependancies during validation.

> 3. QA recieves the "final" version for testing some small number of days
> either before or after the release date, forcing the product out the door
> with non-trivial bugs remaining in the system.

Is "frozen" sufficient for that?  By the time the distribution is frozen,
all the base disks would have to be made, the kernal image would have to
be up to date, etc., etc.


> First: Put less change into the release goals. A simpler set of goals
> takes less time for development and provides more space for testing.
> 
> Second: Set an "internal" release date far in advance of the "public"
> release. This will let developers know that they must meet an earlier
> target and so, bump their schedules to succeed.
> 
> Third: Cultivate a set of users, as beta test sites, who span the range of
> "strange" machines and "difficult" system configurations, who will be
> willing to "fully" test the installation of the new release.

Good.


> With this in mind, here is my proposal:
> 
> 1. Move all source packages to the new source format.
>         a. Shared libraries should provide .shlibs files
>         b. Convert remaining a.out packages
>         c. Fix "installed size" entries in packages
> 
> 2. Re-structure archive sections
>         a. Move all shared libraries into "libs"
>         b. Move interperters out of "devel"
> 
> 3. Pick one or two major areas of improvement to complete.
>         a. Shadow password support
>         b. Impliment the new web server standard
>         c. Multi-thread support in objective-c and the general policy
>         d. Impliment the new startup message standard
> 
> 4. Fix all "critical" bugs
> 
> 5. Fix as many other bugs as possible in the remaining time.
> 
> 6. This has nothing to do with a particular release, but should be an
> ongoing effort in any case:
> Identify and monitor progress on long term projects
>         a. Dselect interface problems
>         b. Comprehensive config tools
>         c. ...your grand idea goes here...
> 
> The current time line published by Brian is still possible if we keep it
> simple and don't try to do everything on the next release.
> We still have several weeks left to solidify our goals (plenty of time,
> even for this group) which gives us a month to create new bugs before the
> freeze and a month to find and fix them.
> We only need to set our goals at a level where accomplishment is possible,
> allow adequate time for testing, and we have the potential to put out our
> first "clean" release.

Well said.
                                             
                                          Brian
                                 ( bcwhite@verisim.com )
                                             
-------------------------------------------------------------------------------
if you have a 50% chance of guessing right,you will guess wrong 75% of the time


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