I agree rb is silly for small patches
On Wed, Apr 3, 2013 at 12:02 AM, Mattmann, Chris A (398J) < [email protected]> wrote: > 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 > >
