On Wed, Jan 05, 2011 at 12:16:33PM +0100, Gregory Collins wrote:
* it is better to ask forgiveness than to get permission
* it is better to avoid tedious discussion even if it means taking 2 steps forward and 1 step back sometimes. Rolling back a controversial patch is an O(1) operation.
Only if it is noticed before the next GHC major release. One of the main reasons the library process was created was to get people to look at changes before it is too late.
* pull scales better than push
What do you mean by that?
* inertia should favour those who want to make forward progress rather than those who would like to slow it down: i.e. it should be easier to get a patch through the process than it should be to slow it down
I think I am one of the more pro-change members of the community, but even I don't think that that is as obviously true as you make it sound. The phrase "forward progress" makes it sound like changes are necessarily a good thing, but some changes are rightly rejected (or improved as a result of the discussion).
* code should speak louder than email on mailing lists.
I don't really know what you mean by that, either. Just because someone submits a patch to do something, doesn't mean that that thing should be done.
* Code and API quality are ensured through a branching/release model rather than through extensive weeks-long patch review.
But shouldn't the same amount of review have to be done either way? Doing it in advance of applying the change just means that we are sure that changes to our core libraries are actually reviewed, rather than no-one getting around to it.
* Code review outside of the core team is accomplished by the fact that someone with commit access needs to apply your patch. For no-brainers discussion would not be necessary, in other cases mailing list discussion might be appropriate. The criterion for accepting changes should not be "is this perfect?" but "is this a net improvement from what we have now?"
* Code review inside the core team is accomplished post-hoc. Any reasonably modern code hosting service can be configured to spam a mailing list with patch notifications or will have an RSS feed you can subscribe to. Remember: rolling back a patch is O(1), and if a patch takes O(n) effort to make, fixing it is usually O(n/k), 2 <= k <= 10.
This is what we had before the library process, and the library process was introduced to fix its problems.
Ian had some criticism for me in our IRC discussion about this issue yesterday, saying: "Have you failed to get a change in you think should have got in?" The fact of the matter is, I would definitely like to contribute but I'm not going near our current process with a 20-foot barge pole.
As someone who uses the process quite merrily, I don't get this. What sort of a changes would you like to contribute, and what problems do you forsee? Is the problem that it will be 2 weeks (or more) before your patch is pushed to a repo? If so, why is that an issue when API-changing releases are only made once a year? Thanks Ian