Making it easier to contribute non-functional changes

[Johan Tibell]

Hi Ross,

Thanks for your feedback.

On Mon, Oct 4, 2010 at 1:45 PM, Ross Paterson <ross at soi.city.ac.uk> wrote:
> 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