ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Patch review process: is there any?
Date Wed, 24 Dec 2014 13:24:56 GMT
On 23.12.2014 02:54, Konstantin Boudnik wrote:
> Guys,
> first of: congrats on moving forward with code base import and fully
> functional website! I also see that people are working quite hard on adding
> new stuff and fixing some post-import issues. Which leads me to this generic
> question:
>  - what's the formal review process of changes, if any?
> From what I see in Apache - and I'm begging veterans here to correct me -
> there are two different school of thoughts:
>  # Review Then Commit (or RTC)
>  # Commit Then Review (or CTR)
> There's no right or wrong way of doing this. And perhaps you might want to
> employ a practice of CaTHWI (or Commit and The Hell With It). It's really up
> to you.

There is one huge advantage of CTR over RTC within the context of the
ASF: RTC tends to create a more closed, less meritocratic community, and
also tends to slow down development of new features. More than once,
I've seen projects that use RTC fragment into a mess of petty
dictatorships, with each significant module being lorded over by a
single developer who had the effective (if not formal) total control
over the direction of development. This situation is as murderous to an
open-source community as a single-point-of-failure is to a distributed
application ... in fact, the similarities are amazingly close.

> Which one is/will be a common practice in the Ignite (incubating)? I haven't
> seen much of discussion on the topic, so I presume you keep on using the same
> practice as it was accepted in the engineering team behind of the product. But
> as the community develops and grows it might be a good idea to think about
> some formal steps in this direction.

I'd also like to bring up another related topic: the structure of the
community. The ASF effectively recognises three categories of community

  * Committer
    Committers have the right to commit changes to any part of the
    project repository. In the CTR model, they're assumed to be
    competent to decide whether a change needs prior peer review or
    whether to just commit it and expect review after the fact; the
    latter being the most common case.
  * PMC
    Members of the PMC are committers who also vote on release
    artefacts, and they decide about accepting new committers to the
    project, and promoting committers to PMC membership.
  * Contributors
    These are members of the project community at large who do not have
    commit privileges, but contribute to the project in many different
    ways; perhaps by sending patches, or writing documentation, or
    helping out on the users@ list, etc. Future committers typically
    come from this group.

At the Subversion project, we have a fourth category:

  * Partial Committer
    Has commit privileges like any other committer, but with the
    understanding that they're only free to practice CTR within a
    well-defined subset of the code (e.g., language translators would
    have partial commit access to a translation; a GSoC student would
    have partial commit access to a branch on which they're developing
    their project code). Otherwise, they're expected to follow RTC. We
    do not enforce this by any kind of access control; any member of the
    community is expected to follow the rules that they adopted when
    they accepted commit privileges.

Some ASF projects (APR and Subversion are examples) do not make a
difference between a committer and a PMC member, so for example at
Subversion, we only have PMC, partial committers and everyone else. The
argument for committer==PMC is a simpel one: if you trust somebody
enough to mess with your code, you should also trust them with oversight
of the project, and the other way around.

Some projects (Subversion again being one of them) give any ASF member
commit privileges to the code without going through a formal vote. The
assumption being that an ASF member will understand that they cannot
make major changes without discussing them with the community, but it's
fine to commit obvious bug fixes without going through the process of
patch submission and review.

-- Brane

View raw message