Proposal: Change to library proposal process

[Duncan Coutts]

On 5 January 2011 11:16, Gregory Collins <greg at gregorycollins.net> wrote:

> The fact of the matter is that pushing patches to a mailing list is OK
> but it's still a barrier to collaboration. Those of us who have spent
> some time working with newer services like github or bitbucket will
> attest that those models are clearly superior for a variety of
> reasons. When someone wants to make a patch for our project, they fork
> our repository on github, code their patch, push it to their forked
> repository, and send us a pull request. Every member of our "core
> team" gets a message in our inboxes and any one of us can apply the
> patches with a couple of keystrokes.

As Stephen mentions, all these things are great for libs where there
is clear ownership by a reasonably small number of people. It is how
most packages in the Haskell world work.

For core libraries like base etc most people feel there needs to be a
more heavyweight process, if just to slow down the rate of change!
That said, it's mainly the APIs that people worry about. I think it
would be fine to have a much more lightweight process for maintenance
or performance stuff that does not change APIs.

At the moment I think we too often refer changes to the libs review
process when they don't change an API and it would be fine for some
suitable individual to review the patch and apply directly. So, yes I
agree we should have maintainers (individuals or teams) for the core
libs, but that API additions/changes should still go through a
community API review process. The maintainers can help contributors
with that process, indeed if the maintainer thinks the change is
sensible they could lead that process themselves.

Duncan