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.
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
>
--
Regards,
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
