On Tue, Oct 05, 2010 at 11:05:07AM +0000, Simon Peyton-Jones wrote:
* I think it's a good idea to create a ticket, to save the proposal getting lost. (The above link suggests creating the ticket in the GHC Trac for any library, which is fine with me so long as its clear.) But it would be a good idea to have some Trac links on the above page that show all open library proposals, so its easy to see all the pending ones.
There are such links, but they're further down the page, so not so easy to find. And perhaps libraries should have a separate Trac from GHC (if only so save Ian from adding "not GHC" to all those tickets).
* The page says "This page documents the mechanism by which new code for libraries maintained by the community may be proposed". Just which libraries are those? I imagine that we mean "exactly those libraries whose maintainer is "libraries@haskell.org"." But we should say so!
It used to say that, but was recently changed: http://haskell.org/haskellwiki/?title=Library_submissions&diff=36838&oldid=36644 At the same time the scope of the process was expanded from proposing changes to library interfaces to proposing new code. That change wasn't discussed here, and I don't agree with it. The changed wording does make it appear that making changes is very cumbersome, but it doesn't match practice: 53 patches were applied to containers in the last 12 months, and only one of them went through the library submissions process. Changes to interfaces are different from non-functional changes, and need a different kind of review. For one thing they are subjective. Also once they get into a release we're stuck with them for at least 12 months and usually much longer. The process needs to apply in the same way to people with and without commit access. If anything that process should be a bit more demanding: I would like to lengthen some of the consideration periods, and move to a "release-candidate" approach. On the other hand we need to make it easier for people without commit access to get minor patches applied. Committers still need to take responsibility for patches they apply, but it's unreasonable to pile all that on Ian, so some restructuring is needed. Maybe a separation between GHC and libraries Tracs would help there too. But mixing these two things will help neither.