The length of time was one of my concerns. The other was having to submit everything as patches to Jira. I can tell you that would really make me think twice to whether I wanted to be a committer or not. My experience has always been that the diff files, which are equivalent to the patch files, are sent via email and get reviewed. The only real difference is the extra overhead that is incurred in every commit for the very infrequent case of when a commit needs to be reverted, and that I would have to keep a sandbox version of the project with just those changes in it so I could commit it when it is approved. Heck, we don't even do that in my $day job. Code reviews always happen after the code is committed.
I can't speak to why the Hadoop related projects do this. I can tell you that a lot of other projects at the ASF produce high quality code and don't do this. Ralph On Aug 5, 2011, at 12:02 PM, Jonathan Hsieh wrote: > Ok, let's amend the proposal and make it more precise. > > One question -- in hadoop, can a committer +1 their own patch or does this > this really mean another committer needs to +1 it? (I'm assuming the latter > but not sure). > > Personally, I actually like getting code reviewed and reviewing code. I've > found that I've learned a lot by looking at other peoples code, that simple > suggestions from another person's review helps over all code quality. > > How's this wording: > > ---- > Code commits for all patches require: > > Lazy consensus of active committers but with a minimum +1 vote or 3 days > passing with no comment. The code can be committed after the first +1 or > after 3 days pass with no comment. > > If the code changes that represent a merge from a branch requires three +1s. > ---- > > Jon. > > On Fri, Aug 5, 2011 at 9:56 AM, Patrick Hunt <[email protected]> wrote: > >> Ralph, your vote is binding "the PPMC is composed of the Podling's >> mentors and initial committers". >> http://incubator.apache.org/guides/ppmc.html >> >> Perhaps you meant to vote "-0" instead? >> http://www.apache.org/foundation/voting.html >> >> All changes at Apache need to go through JIRA regardless of rtc vs ctr. >> >> I agree with Ralph, 7 days is way too long, take a look at Hadoop for >> an alternative: >> http://hadoop.apache.org/bylaws.html >> IMO don't make a distinction btw "trivial" and non - what's trivial to >> me might not be to you. >> >> Patrick >> >> >> On Thu, Aug 4, 2011 at 11:04 PM, Ralph Goers <[email protected]> >> wrote: >>> I didn't realize every non-trivial code change was going to have to be >> submitted to Jira to do this. I don't consider my vote binding but I would >> vote -1. And 7 days feels snail-like. >>> >>> Ralph >>> >>> On Aug 4, 2011, at 4:07 PM, Jonathan Hsieh wrote: >>> >>>> With the code import happening soon, and the RTC vs CTR discussion >> petered >>>> out, and patches waiting to be committed, I'd like to get to an >> agreement >>>> and vote on which style we have for commits/reviews. >>>> >>>> Essentially I'd like to roughly follow our RTC existing mechanism, which >> is >>>> loosely based upon the hbase's how to commit document's review and >> reject >>>> sections. [1] Specifically: >>>> >>>> I propose we have a RTC style project for committers that for any >> nontrivial >>>> patches requires a single +1 or no comment on the review for 7 days (168 >>>> hrs) before commit. >>>> >>>> Please vote: >>>> >>>> +1 to agree >>>> 0 no opinion >>>> -1 to disagree >>>> >>>> [1] http://wiki.apache.org/hadoop/Hbase/HowToCommit >>>> >>>> >>>> -- >>>> // Jonathan Hsieh (shay) >>>> // Software Engineer, Cloudera >>>> // [email protected] >>> >>> >> > > > > -- > // Jonathan Hsieh (shay) > // Software Engineer, Cloudera > // [email protected]
