geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Request change to RTC Process
Date Sat, 03 Jun 2006 22:11:26 GMT

On Jun 3, 2006, at 5:14 AM, Kevan Miller wrote:

> I'd like to request a change to the RTC process being used by  
> Geronimo (or at least I'm requesting a relaxation of Ken's  
> interpretation of the RTC process).
> In Ken's announcement of the change to the commit model, he stated  
> that a +1 to an RTC request means "I have applied this patch and  
> tested it and found it good". Although a relaxation of this  
> interpretation has been suggested (or mentioned), to my knowledge  
> nothing has actually changed.
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and  
> difficult task for most committers. The fact that there are not  
> more committers interested in these areas of Geronimo is an  
> acknowledged issue. However, it's unlikely that current Geronimo  
> committers want to be intimately familiar with some of these  
> Geronimo components -- we've all had our chance to get involved, so  
> far, but have chosen not to.
> That's a specific problem with the current process. However, I  
> think there's a general problem with this interpretation for all  
> areas of Geronimo. IMO, this interpretation is not really helping  
> to address the fundamental problems/concerns which have prompted  
> the move to RTC. IMO, these concerns are that 1) some enhancements  
> are not being properly communicated with the Geronimo community, 2)  
> too many discussions/debates are occurring on private channels, and  
> 3) some people are being intimidated to remain silent on some  
> public discussions.
> I'd like to see some specific RTC guidelines created for Geronimo.  
> I'm sure other projects must have already crafted similar  
> guidelines. So, I'd like to take a look at those, before spending  
> too much time on creating guidelines from scratch (I'd also like to  
> shove 1.1. out the door...)
> In the meantime, I propose the following interpretation of a +1  
> vote to an RTC request:
> "I have reviewed (and possibly tested) this patch and found it  
> good. I understand the capability which the patch is adding and  
> support the direction in which it is taking the Geronimo project"
> Comments and suggestions are, of course, welcome...

I thought Derby was using RTC since they have a policy of all changes  
going through Jira and achieving consensus before being applied.   
However they apparently believe they are CTR.  I reviewed a few  
changes in derby and the maximum review, for a major change that took  
6 months and 9 patch revisions was 2 reviewers.  (DERBY-326)

the derby commit process is described at 

I'm having trouble finding any other apache projects that are RTC.  I  
did find this exchange from 2000: 

The httpd guidelines at say:

Ideas must be review-then-commit; patches can be commit-then-review.  
With a commit-then-review process, we trust that the developer doing  
the commit has a high degree of confidence in the change. Doubtful  
changes, new features, and large-scale overhauls need to be discussed  
before being committed to a repository. Any change that affects the  
semantics of arguments to configurable directives, significantly adds  
to the runtime size of the program, or changes the semantics of an  
existing API function must receive consensus approval on the mailing  
list before being committed. (continues, but mostly on other subjects).

I also see that according to: 

Votes on code modifications follow a different model. In this  
scenario, a negative vote constitutes a veto, which cannot be  
overridden. Again, this model may be modified by a lazy consensus   
declaration when the request for a vote is raised, but the full-stop  
nature of a negative vote is unchanged. Under normal (non-lazy  
consensus) conditions, the proposal requires three positive votes and  
no negative ones in order to pass; if it fails to garner the  
requisite amount of support, it doesn't -- and typically is either  
withdrawn, modified, or simply allowed to languish as an open issue  
until someone gets around to removing it.

  Binding Votes

Who is permitted to vote is, to some extent, a community-specific  
thing. However, the basic rule is that only PMC members have binding  
votes, and all others are either discouraged from voting (to keep the  
noise down) or else have their votes considered of an indicative or  
advisory nature only.

That's the general rule. In actual fact, things tend to be a little  
looser, and procedural votes from developers and committers are  
sometimes considered binding if the voter has acquired enough merit  
and respect in the community. Only votes by PMC members are  
considered binding on code-modification issues, however.
Implications of Voting

If the R-T-C policy is in effect, a positive vote carries the very  
strong implied message, 'I have tested this patch myself, and found  
it good.' Similarly, a negative vote usually means that the patch was  
tested and found to be not-good, although the veto (for such it is in  
this case) may be based on other technical grounds.

This appears to mean that there's no point in non-pmc members voting  
on patches since their votes are considered noise and in any case are  
not binding.

I think that's all the research I want to do today on this subject.


Sachin objected to the comment that it was ok for no one but him to  
ever look at the devtools code.  I agree with Sachin's objection.  I  
think all the subsidiary projects need the attention of more than one  
developer.  Requiring this will I think make us a stronger project.

In any case:

+1 to Kevan's suggested meaning of a +1 vote

In addition I think we should go against the PMC-only rule from the  
voting document and allow +1 and -1 from non-pmc committers to count.

david jencks

> --kevan

View raw message