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] 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 7:07 PM To: "[email protected]" <[email protected]> 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? >> >> >> >> Some people and projects feel the need to develop these specifically >> >> for those projects, however every time I see that, I see extra >> >> conversation, >> >> exclusion,and other things that don't' encourage me to work on those >> >> projects. TL;DR >> >> >> >> Cheers, >> >> Chris >> >> >> >> >> >> On 3/19/13 11:18 AM, "Henry Saputra" <[email protected]> wrote: >> >> >> >> >>> We need to get Tajo into easy to contribute stage with good >> >> >documentations >> >> >>> and good build scripts/tools. >> >> >>> >> >> >>This is not in any way in conflict with RTC. >> >> >> >> >> >Hmm I was actually thinking more about comments or alignment >>cleanups >> >> that >> >> >wont affect any changes to the code. >> >> >I know like ZK prefer to be "dirty" but works and some projects like >> >> Shiro >> >> >has very good code comments and neat alignments. >> >> >My point was these kind of changes may not need review at all. >> >> >I want to hear about community comment to avoid conflict of large >> commits >> >> >that dont change flow of the code at all in the early stage bringing >> the >> >> >source code to good shape. >> >> > >> >> >Community has spoken so standard RTC it is =) >> >> > >> >> >Another question, especially for mentors, should we have bylaws >>setup >> >> >early >> >> >or should we wait a bit longer? >> >> > >> >> > >> >> >- Henry >> >> > >> >> > >> >> >On Tue, Mar 19, 2013 at 10:32 AM, Jakob Homan <[email protected]> >> wrote: >> >> > >> >> >> +1 to standard RTC with reviews before all commits excepting those >> >> >> necessary to fix a broken build. >> >> >> >> >> >> On Tue, Mar 19, 2013 at 10:13 AM, Henry Saputra < >> >> [email protected] >> >> >> >wrote: >> >> >> >> >> >> > I like the RTC but I believe we should not be too strict about >>it >> in >> >> >>the >> >> >> > early phase of incubating project. >> >> >> > >> >> >> It's not about being strict, it's about establishing a culture and >> >> >> community norms. >> >> >> >> >> >> >> >> >> > We need to get Tajo into easy to contribute stage with good >> >> >> documentations >> >> >> > and good build scripts/tools. >> >> >> > >> >> >> This is not in any way in conflict with RTC. >> >> >> >> >> >> > >> >> >> > I would say we use RTC with common sense. If you are in doubt >>fire >> >> >>JIRA + >> >> >> > review. Especially when half of the team are split between day >>and >> >> >>night >> >> >> =) >> >> >> >> >> >> Geographically dispersed teams is a better reason to use RTC as it >> >> gives >> >> >> those still asleep a chance to look at the code before it goes in, >> >> >>avoiding >> >> >> the cost of reverting. >> >> >> >> >> >> Henry, it looks like there's pretty strong consensus to standard >>RTC >> >> >>with >> >> >> 6x+1 for it and Chris' -0 (is that a good characterization, >>Chris). >> >> >> >> >> >> >> >> > >>
