Hi Ross,
Thanks for your feedback.
On Mon, Oct 4, 2010 at 1:45 PM, Ross Paterson
It's already the case that such changes are applied by people with commit access. I agree that the libraries submission process is too heavyweight in such cases. But contributors without commit access need to persuade someone who does to commit for them, e.g. by posting on the libraries list.
My suggestion is that a contributor without commit access simply creates a ticket and assigns it to someone with commit access (e.g. Ian). Aside: Asking who has commit access in an email to the libraries list will quickly get you a link to the libraries process (I tried!). It's very unclear who has commit access to the core libraries. The answer is somewhere along the lines of Ian, the Simons, and some other old timers.
There I disagree -- committers need to make a best effort to be sure of what they are doing, that it doesn't break validate, and that it's not an API change. Breaking the GHC build is a big deal. That means someone asking someone else to commit for them has to demonstrate that it's safe and minor.
I assume that contributor test their patches, just as they would test them before submitting them to a package not maintained by the libraries list. The committer can still review the patch for things that could e.g. break the build. Like you said, a contributor should note in the ticket how he/she made sure that the patch doesn't break things. Note that the library review process today doesn't really look at whether a change will break things so I don't think that skipping the library list review will change anything with respect to build breakages. -- Johan