On Thu, Dec 9, 2010 at 6:42 PM, Ian Lynagh
It sounds like neither of you like the current process. Have you got any better suggestions? (Suggestions which don't put more of the burden on me, please!)
This sort of disagreement is exactly what the process was designed to avoid: People shouldn't be surprised by changes, as they have been discussed and agreed on the mailing list. Unfortunately it was a bit murky in this case, as this change was buried in a proposal for something different: http://www.haskell.org/pipermail/libraries/2010-September/014161.html
I think in future we should take a harder line on reverting accidentally-committed changes, and rejecting changes not clearly part of a proposal, to keep things running smoother.
Here's a proposal: don't have mailing lists maintain libraries. Calling libraries@ a maintainer is a bit of a misnomer: * libraries@ doesn't clean up the code. * libraries@ doesn't write tests. * libraries@ doesn't consider APIs for completeness. * libraries@ doesn't polish documentation. Libraries maintained by the mailing list are only maintained thanks to individuals (the Simons, Ian, other people with commit access) do some spring cleaning outside the libraries process. My suggestion is that every library has a dedicated maintainer (or two), empowered to make changes to the library. That means that everyone want like every change they make, but it's much better than the alternative. Johan