This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Process

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
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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]