Making it easier to contribute non-functional changes

Ross Paterson ross at soi.city.ac.uk
Tue Oct 5 08:55:52 EDT 2010


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 at 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.


More information about the Libraries mailing list