Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

[Tuncer Ayaz]

On 17 February 2016 at 15:47, Austin Seipp <austin at well-typed.com> wrote:
> The better approach, I think, might be to section off certain times
> in a release period where we only allow such changes. Only for a
> month or so, for example, and you're just encouraged to park your
> current work for a little while, during that time, and just improve
> things.
>
> The only problem is, it's not clear if people will want to commit as
> much if the hard rule is just to fix bugs/improve performance for a
> select time. Nobody is obligated to contribute, so it could easily
> fall into a lull period if people get tired of it. But maybe the
> shared sense of community in doing it would help.
>
> Whatever we do, it has to be strict in these times, because in
> practice we have a policy like this ("just bug/perf fixes") during
> the time leading up to the RC, but we always slip and merge other
> things regardless. So, if we do this, we must be quite strict about
> it in practice and police ourselves better, I think.

Exactly, the time-boxing aspect is what I tried to express with my
concern about even/odd branching model, which failed for linux
pre-Bitkeeper. So, maybe a model like Linus does with two weeks of a
merge window and then strictly fixes, but that would require a
ghc-next branch with a maintainer, so probably not feasible with the
resources right now.

> On Wed, Feb 17, 2016 at 7:35 AM, Tuncer Ayaz <tuncer.ayaz at gmail.com> wrote:
> > Here's a thought: has anyone experience with limiting a certain
> > major release to just bug fixes and perf regression fixes, while
> > postponing all feature patches? It sounds like a good idea on
> > paper, but has anyone seen it work, and would this be something to
> > consider for GHC? I'm not suggesting the even/odd versioning
> > scheme, if anyone wonders. These don't work so well and nobody
> > tests odd versions.