Thank you for your favor Chris!
On Tue, Apr 2, 2013 at 1:13 AM, Mattmann, Chris A (388J) < [email protected]> wrote: > 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). > >>> >> > >>> > >>> > >> > >
