Priorities for 6.10

[Claus Reinke]

> GNOME has managed to do this. They have regular 6 month time based
> releases. Everyone knows in advance when the releases will be so nobody
> complains that it should happen sooner (unless they get behind
> schedule). They've managed to make the release process so smooth it's
> almost boring. No fireworks or gnashing of teeth. On the other hand they
> do manage to push out new features to users every 6 months (not
> necessarily from Gtk+ in every release but from many of the other
> components of the platform). They also deliver compatible minor updates
> every few months in between major releases.

In case you hadn't noticed, the 6-monthly HC&A reports have
managed to introduce such a release cycle;-) It just so happens
that GHC HQ has been much better at targetting the deadlines
than general libary authors. There is always at least one release 
candidate cycle for every GHC release, so library authors
could check their libraries long before GHC is released.

Currently, what seems to happen is (lack of humour not marked):

- GHC HQ targets HC&A report dates, with release candidates
    well in time beforehand
- extra-libs get some testing by way of being in HEAD/STABLE
    buildbots
- many other library authors don't do release candidate testing
    (not being aware of GHC RCs, or having more pressing priorities)
- GHC x.1 comes out
- users install GHC x.1
- libraries break
- libraries get fixed, GHC bugs get raised
- GHC bugs get fixed, GHC x.2 comes out
- things settle down

It would indeed make sense to have HLP releases driving, though
most readers of this list tend to have needs forcing them to go with
unbuildable GHC HEAD instead of GHC releases!-)

Note also the splits that are being reinforced by the increasing and
increasingly pragmatically oriented Haskell community:

1 Haskell beginner: wants a complete working system, no advanced
    stuff, but simple versions of tricky things like GUI and web libs

2 Haskell programmer: wants a complete working system, batteries
    included, but is willing/able to add specialist stuff from hackage;
    which might be broken

3 Haskell application/library user: wants to be able to use something
    specific, has to use the GHC version that is able to compile that 
    something; if a library/application they need depends on GADTs/TFs/
    etc, they have to install the GHC version that supports that; which 
    might break other libraries

4 Haskell advanced application/library developers: needs the newest
    GHC features to make their jobs feasable; install/build from
    darcs/hackage/whatever, but don't like interruptions due to
    unnecessary breakage; in particular, need to be able to point
    their users to snapshots that cope with their apps/libs

5 Haskell developer: works on unpublished branches of darcs HEAD,
    or develops/maintains/revamps darcs HEAD

6 Haskell designer: thinks/writes about extensions that might become
    branches of darcs HEAD

The splitting is likely to continue as the Haskell community keeps
growing. Currently, HLP might try to target the first two categories,
and the last three are used to struggling on, but that leaves the third
group in limbo. You can't serve everybody, I guess, not if you want 
to make progress for the majority, but it might help to recall that there 
are more kinds of Haskellers than one might think about at first sight.

|Yes!  I couldn't have put it better, this is exactly the direction I think 
|we should move in.  Rather than a GHC release being the point at which 
|everyone upgrades, the platform takes over that role, and the platform 
|release engineers start from a particular GHC release (perhaps not even the 
|most recent, if the timescales are too tight) when putting together a 
|platform release.

The Squeak-ers (Smalltalk with its image-based model) have release teams
trying to decide what goes in and pulling everything into a coherent image
for each release. They have also been re-discovering the need for standardised 
package distribution models beyond monolithic images recently

|This way we'll have a much more satisfying user experience than when 6.8.1 
|was released with large tracts of Hackage unusable.

Will there be buildbots, and a buildbot report and release cycle discussion
list for HLP, to help raise the standards of HLP beyond hackage toward
that of extralibs?

Also, if GHC keeps in sync with HC&A, will HLP be out of sync,
or lagging by a full six months? Or, if HLP is supposed to be driving,
should GHC target the midpoints between HC&A report dates?

Claus