Making it easier to contribute non-functional changes

[Ross Paterson]

On Mon, Oct 04, 2010 at 12:03:22PM -0400, Johan Tibell wrote:
> Only changes that don't affect the API or performance (in non-trivial
> ways) should be allowed in without a review. Examples of patches that
> shouldn't require review: addition of tests/benchmarks, smaller
> documentation improvements, internal reorganization, updates due to
> compiler changes, etc.

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.

> It's possible that once a commit that should have been reviewed gets
> commited. I suggest we adopt an "ask for forgiveness, not for
> permission" policy in these cases. We can always roll back changes.
> 
> N.B. If someone (e.g. Ian) commits patches of this nature on someone
> else's behalf, that person should not be held responsible if the
> patches are rolled back later.

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.