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