Proposal: Change to library proposal process

[Ian Lynagh]

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