+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). > >> >> > >> > >> > > >
