Re: Process

[Phil Muldoon <pmuldoon at redhat dot 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
>   share).
>
>   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
>   major imposition.
>   

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.

Regards

Phil