New libraries process

[Johan Tibell]

On Thu, May 19, 2011 at 2:18 PM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> No, we intended that the  maintainer is never *required* to accept a change.  To quote "the community offers opinions; the maintainer decides".   If you think that point should be made even more strongly, can you go ahead and edit?

No, I think it's fine. Once I got down to do the detailed review I
forgot that this important principle had already been stated.

> | 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.
>
> Our intention was to make sure that the community had *some* opportunity to comment on a change that may affect them.   You point about public APIs is a good one -- for internal changes perhaps all a proposer needs to is to persuade the maintainer.  (Or, if the proposer is the maintainer, persuade himself.)

Good to know that internal changes doesn't need review. Would an
ask-for-forgiveness model work i.e. if the maintainer makes some
radical change someone who reads the commit emails could complain and
have the change reverted.

> | 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)?
>
> So this is a public-API change, but you could argue that it's one that cannot hurt a client because it's only widening the interface.
>
> What about if you wanted to change the signature of a function in the API.  Wouldn't it be reasonably to give your community a chance to react?

I don't think we need to equate "chance to react" with upfront review.
Once can react by e.g. following commit messages.

> | Depends entirely on what the process ends up being.
>
> Good.  I'll be dissatisfied if we don't end up with a process that you think is sane.

I'd like to set some expectations here. My current belief is that the
process that's used to managed e.g. bytestring, text, and network is
fine. That is the default the-maintainer-knows-what-he's-doing open
source approach. I'll try to be open to any restrictions to that, but
this is the point I'm starting at.

Cheers,
Johan