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/