Hey Henry, Yep agreed. Assume that's the case I would say unless someone objects :)
In which case, talk and communicate, yadda, yadda, which you already know. Enjoy! Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Henry Saputra <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, April 2, 2013 9:00 PM To: "[email protected]" <[email protected]> Subject: Re: a discussion of dev process >Ah no, I meant that when someone submit a patch he or she shouldn't >required to create rb entry. It should be used as reccomended way to >submit >patch to help review > >- Henry > >On Tuesday, April 2, 2013, Mattmann, Chris A (398J) wrote: > >> Hey Henry, >> >> I don't understand your comment -- isn't Review Board useless without >> a patch? >> >> Cheers, >> Chris >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Chris Mattmann, Ph.D. >> Senior Computer Scientist >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> Office: 171-266B, Mailstop: 171-246 >> Email: [email protected] <javascript:;> >> WWW: http://sunset.usc.edu/~mattmann/ >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Adjunct Assistant Professor, Computer Science Department >> University of Southern California, Los Angeles, CA 90089 USA >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> >> >> >> -----Original Message----- >> From: Henry Saputra <[email protected] <javascript:;>> >> Reply-To: "[email protected] <javascript:;>" < >> [email protected] <javascript:;>> >> Date: Tuesday, April 2, 2013 7:07 PM >> To: "[email protected] <javascript:;>" < >> [email protected] <javascript:;>> >> Subject: Re: a discussion of dev process >> >> >+1 for it as long as patches are not required to create reviewboard >>entry. >> >It should be used as tool to help review large patches such as new >> >features >> >or refactor some code. >> > >> >- Henry >> > >> > >> >On Mon, Apr 1, 2013 at 9:12 AM, Hyunsik Choi <[email protected]> >>wrote: >> > >> >> I've requested the reviewboard. As we've been doing so far, we can >>use >> >>jira >> >> in order to share the patch and review it. In addition, we will be >>able >> >>to >> >> use reviewboard. >> >> >> >> https://issues.apache.org/jira/browse/INFRA-6084 >> >> >> >> - hyunsik >> >> >> >> >> >> On Wed, Mar 20, 2013 at 3:49 PM, Hyunsik Choi <[email protected]> >> >>wrote: >> >> >> >> > Hi Guys, >> >> > >> >> > Actually, I agree with Mattmann in that not all patches need to be >> >> > reviewed. Also, I agree with Jakob in that we should avoid the >> >>problems >> >> > caused by unexpected commits. >> >> > >> >> > How about this? Basically, we use RTC with only +1 vote passing >>before >> >> > merging a patch to master branch (i.e., trunk in svn term). Also, >>some >> >> > cases (e.g., trivial changes and site updates) do not require +1. >> >>This is >> >> > very simple. This approach will let us to avoid the significant >> >>problem >> >> > caused by unexpected commits, while it will mitigate the stress of >> >>heavy >> >> > process. Of course, each committer by itself has to determine >>whether >> >>a >> >> > patch is trivial or not. Since the committers will have the >>capability >> >> for >> >> > this, it may be not problem. >> >> > >> >> > Also, I think that three steps (creating a branch, working, and >> >>merging >> >> > the patch to master with consensus) suggested by Chris are very >>cool. >> >>We >> >> > can use this approach for some works. This approach will be also a >> >> > convenient way to share on-going patches. In addition, this >>approach >> >>can >> >> > encourage two or more committers to collaborate on the same work. >>In >> >>some >> >> > cases, it can make some synergy. >> >> > >> >> > Thanks, >> >> > Hyunsik >> >> > >> >> > >> >> > >> >> > >> >> > On Wed, Mar 20, 2013 at 3:56 AM, Mattmann, Chris A (388J) < >> >> > [email protected]> wrote: >> >> > >> >> >> Hi Guys, >> >> >> >> >> >> It's up to you. I've never been a fan of project bylaws. >> >> >> >> >> >> To me they "anticipate" things needing clarifying whereas to me, >> >> >> the discussions on list, the meetings at ApacheCon, the day to day >> >> >> interactions that occur however, are much more socially fun, and >> >> >> wholly enjoyable to participate in then: >> >> >> >> >> >> "According to bylaw G, you are an X committer, in a year, you can >> >> become a >> >> >> PMC member, etc." >> >> >> "Per the bylaws, which are different than the general Apache >> >>guidelines, >> >> >> VOTEs are required >> >> >> to have a x/4 majority, except for Tuesday, on which" blah blah >>blah >> >> >> >> >> >> http://www.apache.org/foundation/how-it-works.html >> >> >> >> >> >> http://www.apache.org/foundation/voting.html >> >> >> >> >> >> http://incubator.apache.org/guides/ppmc.html >> >> >> >> >> >> http://www.apache.org/dev/committers.html >> >> >> >> >> >> >> >> >> Anyone object to simply stating those above along with social >>graces, >> >> >> and communication, are the bylaws for the project? >> >> >> >> >> >> S
