release schedule and Linux distros

[Iain Lane]

Hi there,

Sorry for taking a while to reply. I was away and then forgot. :P

I'm indeed not on this list so please CC me in any replies that you want
me to see.

On Thu, Jun 07, 2012 at 10:11:24AM +0200, Joachim Breitner wrote:
> […]
> > For example looking at the coming Fedora 18 development cycle [2] the
> > Alpha freeze is currently 2012-08-14 and Beta freeze is set for
> > 2012-09-18.
> > So for Fedora at least, if we wanted to have ghc-7.4.2+ and Haskell
> > Platform 2012.4 in the next release (we just released Fedora 17 with
> > haskell-platform-2011.4...), then I think we would need the final
> > 2012.4 release in August and an alpha/beta release in July.  I imagine
> > the cut-off dates for Ubuntu might be roughly a month earlier say, but
> > hopefully the Ubuntu people can chime in on their thoughts too?

Our current release schedule is

  https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule

The freeze we should be aiming to have all major churn in by is Feature
Freeze. So that's August 23 for this release, and roughly every six
months (give or take a couple of weeks) thereafter.

> > Otherwise at least for the Fedora 18 release in November probably we
> > will just stick with ghc-7.4.1 and HP 2012.2 to follow the stable
> > platform.  The current HP schedule of a final in November is really
> > too late for Fedora 18 and Ubuntu 12.10, but maybe okay for Fedora 19
> > and Ubuntu 13.04: though that is quite a lag, which is the problem I
> > am trying to highlight in this mail.

Yes, it is. I'd like if if there were snapshot releases (call them
'alpha', 'beta' and 'release candidate') throughout the development
cycle, so that we can better ensure that we're sticking to the platform
without having to watch the repository.

> > 
> > If others have thoughts or ideas for improving the turnaround time for
> > Linux Haskell Platform and making Linux more of a first class HP
> > citzen, I would be interested to hear them.
> > 
> > Personally I would favour maybe decoupling the HP source and binary
> > releases completely, and also doing more regular developmental HP
> > releases between the stable ones to make it a more continuous
> > opensource process.
> 
> 
> speaking for Debian: Our release process is probably a bit too
> unpredictable for a fixed date. We do, however, benefit from early
> version bumps in the pre-release branch; the mtl/transformer transition
> is still not finished in Debian (due to having to rebuild almost 200
> packages and some architectures like sparc being a bit slow these days).
> Knowing about the packages versions earlier means less work after the
> official release of the platform.

I also want to say that we (both Debian and Ubuntu) tend not to stick
too rigidly to the platform's versions of packages. This is for two main
reasons that I can think of

  - Applications or other libraries that we need for whatever reason
    force us to increase (or hold back) the version of a library
    specified in the platform.
  - There are fixes in something specified in the platform that we
    definitely want in the release. A good example right now is that GHC
    7.4.2 contains some very nice ARM and PPC fixes that we almost
    definitely want in. If we wanted to remain strictly
    platform-compliant with the current released version, we'd have to
    start cherry-picking fixes which is a bit sad. As it is I'll
    probably want to put this into Ubuntu and then reconcile it with
    whatever platform we have available at release time.

The platform could probably be a bit more flexible around minor
versions to allow distros some wiggle room here.

Cheers,

-- 
Iain Lane                                  [ iain at orangesquash.org.uk ]
Debian Developer                                   [ laney at debian.org ]
Ubuntu Developer                                   [ laney at ubuntu.com ]
PhD student                                       [ ial at cs.nott.ac.uk ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20120615/e1fb2333/attachment.pgp>