Proposal: Make gcd total

[Simon Marlow]

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