Reviving the LTS Discussions (ALT: A separate LTS branch)

[Austin Seipp]

Hi *,

I want to draw attention to a topic that's come up a few times before,
spurred by discussion a few weeks ago by John Lato, and more
frequently (in other forms) by people like Gintautaus, with people
taking more mindshare in merging and getting patches and features
flowing.

The basic problem boils down to: what do we do about long term
releases for GHC, how can we manage them, and what sort of effort
would be required to maintain something like that?

The problem with GHC has always been one of time allocation for
humans. And we're really aggressive about fixing problems and
addressing things, with frequent updates and improvements to lots of
our core features.

That's fantastic! I am constantly amazed that despite almost all of
our contributions being major volunteer work. But that comes as a cost
in other ways:

  1) We have very little resources dedicated to maintaining things
like a long term branch. I certainly cannot do it alone while having
enough time to sensibly manage everything else I do.

  2) High rates of churn often 'leave people in the dust'. When you
refactor a big ball of code, and you improve it, you often don't want
to think about the old ball of code. And having to remember the old
ball of code from 6 months ago can be a significant undertaking, even
for the best of us.

  3) High rates of churn can introduce new bugs. While in my personal
and professional experience I think Haskell is exceptional at
preventing bugs, and we have lots of tests for GHC to catch
regressions, we can often break things. The rate of this is not clear
because it's got a significant amount of variables attached.

1 and 3 hurt users. 2 hurts developers. All of them are unfortunate.
There are a lot of these kinds of issues in various forms but the
specifics can be discussed later.

So what does this have to do with John's email he sent me.

Well, he had a helpful idea that's been picked up by most other
people: we should have a separated stable team that deals with longer
term maintenance.

The pattern of a separated stable/longterm team is actually one that's
common in a lot of older and higher profile FOSS projects, where
people maintaining long term versions are dedicated developers, but
simply on a different schedule than others. It's just two teams on one
project: same goal, different priorities and needs.

The question is who's going to do it of course - but I'm hoping our
volunteer streak will kick in. :)

There are some advantages to this:

  1) We can pick a stable branch, and we can have a separated group of
people maintain it.

  2) Most developers workflows won't change in the majority of cases,
and we can keep on humming along.

  3) Users can have an 'endorsed' version that we delegate as a stable
compiler for a designated period of time, based on the LTS Team's
projections.

But there are still some more difficulties:

  1) We need to decide how to pick a LTS branch, and when. The current
release cycle *roughly speaking* dedicates about a year to each
release, while HEAD steams along. Do we turn each major release into
an LTS branch, and give it over to the LTS team, or do we only
consider every other release, or do we pick and choose?

  2) We need to define a scope of things an LTS branch would address.
For example, API stability, what kind of bugfixes we get in (simple
mitigations vs thorough fixes that may be more substantial).

  3) We probably need some policies on working conventions. For
example, using the bug tracker, how to assign people to bugs, and how
to make sure everyone is on the same page.

  4) We need to decide who's going to do what.

So, to be clear, I would suggest having a separate group of committers
who can follow a designated long term branch, and maintain it. These
people do not necessarily need to contribute upstream features or
massive things, but do need to show pretty clear commitment and
stewardship. I think if we start this, we'll have to sort of do self
nominations the first time, since there may be
new-but-interested-GHC-hackers who might want to help.

Beyond that, as mentioned above, we need to define scope, and some
technical procedures. But this can all be hashed over VoIP, the lists,
etc etc.

I've tried to think up a good start to this conversation, and I think
John's suggestion is a good one - so I'm eager to see where it goes
this time.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/