[OT] Why there is no release schedule [Was: Release Date of Woody?]

[ferret@phonewave.net]

On Mon, 18 Dec 2000, Harald Dunkel wrote:

> Jan Martin Mathiassen wrote:
> > 
> > now, tell me, why are you so hell-bent on getting a firm release date for
> > woody?
> > 
> 
> I asked whether a release schedule exists. It was not my intention 
> to influence a possible release schedule in any way or to push 
> anybody to create one.

Harri:

Basically there is no release schedule, just release GOALS which are the
things that need to be accomplished before release. In a purely volunteer
organisation such as Debian release schedules are impossible to enforce.

However, it is recognised that the currect efective 'release schedule' of
around 18 months is rather long for most people's tastes, so we're doing
what we can in a technical manner to reduce the total latency in the
release, which should actually shorten it. Note we still don't really use
schedule-based goals. It's been done and there is just no way for
volunteers to follow a schedule.

Generally, the big things that determine the actual release are:

* Installation system: This has been always re-worked, as far as I know,
  because always there is some new feature that didn't exist before in
  the kernel or base utilities, or new hardware that suggests a
  different installation method (I worked on Zip/LS120 support for
  Potato), or everything has just grown so much that we need to re-write
  (which is what's happening for Woody - a much finer-grained
  installation system is needed just to handle such divers systems)

* Release-critical bugs: Basically this covers anything that would
  prevent a new system from being installed due to codebugs or packaging
  'issues', or issues with packages not being able to work with the
  now-current versions of standard or required packages, or issues with
  the installation images or the package mirrors not working.

* Testing: This is a little bit below the level of release-critical
  bugs. Basically here we get people to either install or upgrade from
  the previous stable release or the release before that, and report
  back any problems. Note that this stage can GENERATE new
  release-critical bugs. This is also one of the few points where we CAN
  get away with publishing a schedule, and this schedule can only be
  TENATIVE because packages of Important or Required must to be fixed
  anyway; all other packages that have unfixed release-critical bugs at
  this point are dropped from the release if they don't meet the release.

Now, the transition to package pools, though it's actually breaking
'woody' in the short term because of the change in name mapping, is
supposed to help the second two issues be resolved more quickly by
spreading the testing phase of the release cycle over a proportionately
longer period.