On 17 February 2016 at 15:47, Austin Seipp <aus...@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.a...@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. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs