Final word on OpenAL?

[Duncan Coutts]

[ also resending because the cc keeps getting changed to
haskell-platform at community.haskell.org which does not exist!! ]

On Thu, 2009-04-30 at 19:55 +0200, Sven Panne wrote:
> Am Donnerstag, 30. April 2009 19:19:54 schrieb Don Stewart:
> > We definitely want to avoid a culture of "packing in bug fixes and
> > features" prior to release, though, as that's a recipe for new bugs!
> 
> I fully understand this, but due to the extremely poor communication of the 
> schedule, this is a far better option than shipping something which has non-
> trivial bugs.
> 
> I wouldn't propose this if I had known the release date some months in 
> advance. Expecting everybody to happy when you suddenly shout out a release 
> date is a bit too much IMHO...

You're quite right that the release date has been poorly communicated.
I'm sorry about that. It's partly my fault and partly inevitable for a
first release (because we cannot release before certain things work).
It's also partly that we were not expecting any new releases of any of
the packages, so we were not asking maintainers for their updates. All
the package versions we're selecting are pretty stable (ie they've been
available for some time).

The point however is that we're trying to design a release procedure
that will scale to many packages and many maintainers. That means
time-based releases in future with dates known well in advance. It means
trying to get a procedure where we do not have last minute scrambles. We
can do that in two ways, having releases sufficiently frequently that
there is not this massive pressure to get everything in all at once and
two by incrementally freezing changes as we get nearer to a release.

For example in the GNOME release procedure (which coordinates ~100
packages and a similar number of package maintainers) they freeze API
changes some 4-6 weeks before the release and even code changes are
frozen in the week or so before the release. This lets people
concentrate on testing the integration.

Now, for this release we could say that it's an exception because it's
the first one and there was no announced date etc etc and let the GL
updates in. But it doesn't really set the right tone if we are already
making exceptions to the rules.

Under a normal steady-state procedure, if the release were on this
coming Monday then it'd absolutely be too late to include any bug fixes
from any packages. New features would certainly be out.

However even then it would not be a big problem because the next minor
release is slated for 4 weeks after the initial release. We've had these
GL bugs in the available version since the beginning of November. I
expect we can live with them for another 4 weeks. As for new features,
there is nothing preventing new releases on Hackage in the 6 months
between major releases.

So, I apologise for the poor communication with maintainers and I'm
prepared to be persuaded if everyone else agrees that version bumps
should go in at this stage but my personal opinion is that we should
stick for this release and roll the updates into the next minor release
in 4 weeks time.

Duncan