On Tue, Sep 15, 2015 at 08:43PM, Evans Ye wrote: > There're some points made by Olaf and I think they're valuable. But I think > we can get the benefit of reviewing process by applying some policy to our > CTR. > > For example, one is forced to drop a patch on JIRA and wait for a certain > while before commit. > Someone interested in it may take a look at patch and left a comment. > Comments need to be addressed as well as consensus should be reached then a > patch can be committed.
Similar logic can be applied in the opposite direction: if someone make a commit that breaks something he will be responsible to address the issues. If a commit is made that is suboptimal from the design standpoint and others have pointed to it - the commit can be reversed. We use a version control after all, so no changes are irreversible. > The benefit of CTR to me is that some minor improvement or bugfix that do > not have design issue can be fixed earlier and then things can move > forward. I see sometimes patch get stalled and no one is looking into it, > which is sort of depressing to either committer or contributor who creates > it. But I do know everyone is busy and we might just being lack of > resources. If we adopt CTR and committers' load can be alleviated. We can > spend time on things that need to be discussed more. We can spend time > helping more contributors on board. Hear, hear! Given that CTR will require us to be thorough when we are inviting new committers and make sure that we extend the commit-bit to people who aren't just shooting from the hip. But that's a little price to pay, in my opinion. > Getting back to CI, maybe this is a good chance to improve it based on what > we really need in the field by adopting CTR. What I mean is what I proposed > earlier might looks like the best case for our CI, but maybe there're > something we don't really need that much. So, if we have our CI at least > cover all the major functionality, then we should be good to go. +1 > > Evans > 2015年9月15日 上午6:07於 "Andrew Purtell" <[email protected]>寫道： > > > Yes, please! :-) > > > > On Mon, Sep 14, 2015 at 10:33 AM, Andrew Musselman < > > [email protected]> wrote: > > > > > If you guys are looking for some help with > > > https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at > > > work > > > to see who might have the interest and bandwidth. > > > > > > On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell < > > [email protected] > > > > > > > wrote: > > > > > > > Just to be clear I didn't simply describe what the HBase community is > > > > doing in this regard but also submitted those ideas for consideration > > > here. > > > > I could make the same dismissive statement about your pointer to the > > > Ignite > > > > lists. > > > > > > > > > > > > > On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <[email protected]> > > > wrote: > > > > > > > > > > What Andrew describes is a good step forward CTR process and I am > > sure > > > > HBase > > > > > community will find a process that works for them the best. I still > > > > think CTR > > > > > and yet another step further. I believe if a person has commit-bit it > > > is, > > > > > essentially, means that his judgement is trusted and he knows what's > > > > good to > > > > > the project and won't hurt the code intentionally. Mistakes will be > > > > happening > > > > > under either of the processes. But the trust in your community > > fellows > > > > goes > > > > > long way, I think. > > > > > > > > > > We had this discussion on Ignite dev@ list just about a month ago > > [1]. > > > > And all > > > > > sorts of arguments were expressed there, and I'd encourage everyone > > to > > > > spend > > > > > a little bit of time reviewing it. The great points were made by > > Brane > > > > [2], > > > > > [3], and [4]. They aren't that long and esp. [3] is very deep, in my > > > > option. > > > > > > > > > > Considering that I really agree with what Brane and myself (doug ;) > > > have > > > > said > > > > > on that thread I won't repeat myself here, but just ask to look at > > the > > > > last > > > > > three emails from below. > > > > > > > > > > BTW, Ignite is on the CTR process for about a month now - nothing > > > morbid > > > > had > > > > > happened to it. And the rate of the development in this project is > > > pretty > > > > > high, actually. > > > > > > > > > > Thanks, > > > > > Cos > > > > > > > > > > [1] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html > > > > > > > > > > [2] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html > > > > > [3] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html > > > > > [4] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html > > > > > > > > > >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote: > > > > >> I made this argument over on the dev@hbase list: If the community > > > > considers > > > > >> quality a priority (and we do, right? (Smile)) then we should have a > > > > strong > > > > >> code review ethic whether technically bound to have one (RTC) or not > > > > (CTR). > > > > >> > > > > >> I started a discussion to move over to CTR on HBase because some > > > > components > > > > >> or niche concerns don't draw prompt reviews, slowing down the > > > > >> contributor/committer because their next steps depend on the current > > > > patch. > > > > >> We had this discussion on our dev@ list. You can find it in the > > > public > > > > >> archives if curious. However I was mostly convinced we have > > sufficient > > > > tools > > > > >> without CTR so that's not necessary, eg: - Any committer can check > > > > anything > > > > >> into a dev branch (non release branch) without review; review comes > > > > later at > > > > >> the branch merge vote. Haven't checked if we have a branch merge > > > > policy. We > > > > >> can always add one. > > > > >> - Small fixes or test only changes are given leeway to the > > committer's > > > > >> discretion. Try to wait long enough if a volunteer wants to show up > > > and > > > > do a > > > > >> review. - We have an informal consensus practice where as long as > > the > > > > >> change doesn't have major impact (again, committer discretion) then > > > > after an > > > > >> issue sits a day or two one might post "going to commit this later > > > today > > > > >> unless objection" - and, if no objection, this is a "lazy review" > > and > > > > >> commit. > > > > >> > > > > >> For your consideration. > > > > >> > > > > >> > > > > >>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <[email protected]> > > wrote: > > > > >>> > > > > >>> I don't want to derail this decision if CTR has general approval. > > I > > > > would > > > > >>> be happy with a clear checklist document that we can all agree to > > > > follow > > > > >>> before commits. > > > > >>> > > > > >>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas < > > > [email protected] > > > > > > > > > >>> wrote: > > > > >>> > > > > >>>> i think we moved this discussion here > > > > >>>> https://issues.apache.org/jira/browse/BIGTOP-1249 > > > > >>>> > > > > >>>> The goal is definetely to get automated reviews. > > > > >>>> > > > > >>>> we hacked around successfully with some prototypes but never > > > > productionized > > > > >>>> them. > > > > >>>> > > > > > > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > >
