Process

[Tom Tromey <tromey at redhat dot com>]

We talked a bit at the meeting about a proposed development process.

The scratch proposal is something vaguely apache/subversion-ish.  Note
that we can tweak this as needed.

* Mandatory patch review: any patch must be reviewed by at least one
  person other than the author.  Anybody "in the project" can review
  ("+1") a patch (and for Red Hat folks -- everybody has to do their
  share).

  I think a single +1 should be enough for the time being.  But, I
  don't feel strongly about this -- any preferences?

* A strong objection (aka "-1") should stall a patch until a rough
  consensus is reached.  FWIW the "rough" is meant to imply a
  requirement of reasonableness on both sides of a disagreement.

  I think the most common case here is that a reviewer will ask for
  some changes.

* We'll defer deciding how to approve new reviewers until the need
  arises.  Probably voting or rough consensus.

* Some proposed baselines for patch review:

    - Does it have internal documentation (comments)?
    - Does it follow upstream coding style?
    - Does it have external documentation, if needed?
    - Does it have a test case, if needed?
    - Is it clear and complete?
    - A GCC-like rule: a submitter should say how the patch was
      tested; reviewers can assume that there were no regressions.

* Upstream rule: I think we should require FSF assignment paperwork,
  so that we can push changes upstream.  I don't think this will be a
  major imposition.

Let me know what you think.

Tom