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
