Cool I love Review Board Hyunsik thanks! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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: Hyunsik Choi <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Monday, April 1, 2013 9:12 AM To: tajo-dev <[email protected]> Subject: Re: a discussion of dev process >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). >>> >> >>> >>> >>
