Sounds great; thanks all. On Mon, Sep 14, 2015 at 11:15 AM, Jay Vyas <[email protected]> wrote:
> Thanks Andrew. As per our conversation on Twitter it will be exciting to > add more engineers to the maintainable of the automated patch reviews. We > can help provide feedback on getting started, of course. > > Just have your guys ping us on the mailing list and we will maybe schedule > a google hangout to discuss the best way to setup automation. > > > On Sep 14, 2015, at 1:33 PM, 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. > >> >
