This is the mail archive of the
mailing list for the Archer project.
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Fri, 25 Jul 2008 13:57:41 +0100
- Subject: Re: Process
- References: <email@example.com>
Tom Tromey wrote:
* 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?
I think one is okay too.
* 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.
As long as a strong objection is exactly that. A strong, profound and
well-argued objection. And not using -1 for nit-picks. I don't think
this will happen, but just stating my opinion for the archives ;)
* 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.
Yeah. I'll elaborate further here. My desire would be that the submitter
should make sure that the patch does not regress any existing
test-cases. As a test-suite is a good indicator of a project's health, I
think this is super important. Now whether the archer test-suite will be
a subset of the existing GDB test-suite is open for debate. A statement
by the submitter - as you wrote up in the GCC line-item - would be good.
What architectures are our submitters expected to the test their changes
against? Is there a core set?
* 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
Again this is probably stating what is implied already, but if there are
no patch-dependencies holding another patch back in Archer, it should be
merged upstream. I'd like the original author to do this, but understand
differences here. Personally my goal is to attain commit after review
status upstream as a soon as possible, to enable travel between both
projects as needed.