On 19/05/2011 10:47, Johan Tibell wrote:
Section 3:
It's not clear when the "deadline for discussion" should be used. Does
it apply to any change or only public API changes? Does it apply even
if it's the maintainer that making the change? Having to spent two
weeks (even though most of the time is spent waiting) to make a single
change is too high an overhead for me. I suspect I would just not
bother making the change.
That's the tradeoff. These are *core* libraries that lots of people
depend on, therefore there is a bigger barrier to change, and we want to
subject all changes to greater scrutinee than we would for a random
Hackage library. When we proposed giving maintainers full autonomy,
there was pushback from some people who felt strongly that changes in
core APIs should be required to be discussed in public, so we backed off
from the fully-autonomous position to this, which I think is a good
compromise.
I think we should also find a way to make larger changes to the core
libraries (perhaps by having two branches), but for the typical
day-to-day development I think this process makes sense.
To make things more concrete, what steps are
required of the (future) maintainer of containers who wants to add a
strict version of some function (many functions are missing a strict
version at the moment)?
They announce their intention on the mailing list, wait a while, and
then assuming the ensuing discussion does not persuade the maintainer
that the change is a bad idea after all, go ahead and make the change.
Use common sense to decide what "a while" means. We want to avoid
having too much process, but we do want API changes to be discussed on
the mailing list *prior* to the change being set in stone.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
