Re: Request change to RTC Process

[David Jencks]

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 http://wiki.apache.org/db-derby/DerbyCommitProcess I'm having trouble finding any other apache projects that are RTC.  I did find this exchange from 2000: http://marc2.theaimsgroup.com/?t=96942591500015&r=1&w=2 The httpd guidelines at http://httpd.apache.org/dev/guidelines.html 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: http://www.apache.org/foundation/voting.html 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.  thanks david jencks --kevan