This is the mail archive of the
mailing list for the Archer project.
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Thu, 24 Jul 2008 14:51:34 -0600
- Subject: Process
- Reply-to: 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
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
* 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
Let me know what you think.