It seems things are going pretty well under CTR: * Committers are more productive * Nothing went wrong seriously * Concern on patches are addressed
So I'm +1 to make CTR model permanent. 2015-11-17 10:31 GMT+08:00 Konstantin Boudnik <[email protected]>: > Next week will be two months since we pushed BIGTOP-2069 introducing a > trial > period of the project's CTR development model. I am happy to say that we > haven't broke the project ;) And now with the new better working CI the > chances of it are even slimmer, IMO. Once we have an automatic deployment > and > testing, we'll be even in the better shape. > > Hence, I'd like to revisit the conversation from September and gauge the > consensus of CTR model to become permanent? > > Thoughts? > Cos > > On Tue, Sep 22, 2015 at 05:01PM, Konstantin Boudnik wrote: > > Looks like we have the lazy consensus on this. Let's move forward with > > two-months trial, conditional on CI being recovered after the current > issues > > with disk space getting filled quickly. So, I presume we'll start after > the > > ApacheCon EU. > > > > I propose the following work-flow for CTR and document it in the > top-level > > README. Here's the patch: > > > > diff --git README.md README.md > > index 6342f92..23062a6 100644 > > --- README.md > > +++ README.md > > @@ -55,6 +55,27 @@ There are lots of ways to contribute. People with > different expertise can help > > > > Also, opening [JIRA's](https://issues.apache.org/jira/browse/BIGTOP) > and getting started by posting on the mailing list is helpful. > > > > +CTR model trial > > +=============== > > + > > +As discussed on the dev@ list (http://bit.ly/1gLeArc) we are going > into a trial > > +period of CTR model for Bigtop project. The trial will go into effect > until > > +Dec, 5th, 2015 or for two months since the master CI disk space issues > are resolve, > > +whichever comes first. The following rules will be used for the CTR > process: > > + * a committer can go ahead and commit the patch without mandatory > review if > > + felt confident in its quality (e.g. reasonable testing has been done > > + locally; all compilations pass; RAT check is passed; the patch > follows > > + coding guidelines) > > + * a committer is encouraged to seek peer-review and/or advice before > hand if > > + there're doubts in the approach taken, design decision, or > implementation > > + details > > + * a committer should keep an eye on the official CI builds at > > + http://ci.bigtop.apache.org:8080/view/Bigtop-trunk/ > (Docker-Bigtop-* > > + builds) to make sure that committed changes haven't break anything. > In > > + which case the committer should take a timely effort to resolve the > issues > > + and unblock the others in the community > > + * there's no changes in the JIRA process, except as specified above > > + > > What do people use Apache Bigtop for? > > ============================== > > > > ---- end of the patch > > > > If the above looks ok for everybody I will go ahead and commit this in a > couple > > of days, once I regain the network connection. > > > > Regards, > > Cos > > > > On Sun, Sep 20, 2015 at 03:23AM, Evans Ye wrote: > > > Ofcourse if that doesnt fit we can roll back to RTC :) > > > 2015年9月20日 上午3:20於 "Evans Ye" <[email protected]>寫道： > > > > > > > This is way better than mine! > > > > With practical use & try we can have concrete idea of how CTR works > in our > > > > community. We can develop our policy to handle real world cases > instead of > > > > just imaging it. > > > > 2015年9月20日 上午3:11於 "Konstantin Boudnik" <[email protected]>寫道： > > > > > > > >> I'd rather avoid or at least postpone the voting until we have > everyone > > > >> being > > > >> comfortable with the proposed changed. I really don't like an idea > of > > > >> someone > > > >> being in minority and being forced to play alone. On the other > hand, I > > > >> see a > > > >> bunch of situations where CTR would be beneficial e.g BIGTOP-2057. > > > >> > > > >> If as Evans said all questions were answered, let's proceed to > voting. If > > > >> not > > > >> - let's give CTR a try for say a couple of months and see how it > works for > > > >> everybody. We hardly can do any irreversible harm even if we try - > we can > > > >> always revert anything we don't like ;) > > > >> > > > >> Cos > > > >> > > > >> On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote: > > > >> > To summarise this discussing thread, I think we have most of our > team > > > >> > member supporting CTR model and questions from RTC advocates are > > > >> answered. > > > >> > I propose to start a vote to officially made decision wether or > not to > > > >> > switch to CTR. > > > >> > If that passed, we then start drafting our CTR policy through > > > >> discussion. > > > >> > Any other thoughts? > > > >> > > > > >> > 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <[email protected]>: > > > >> > > > > >> > > Can I ask RTC advocate to review a couple of patches to unblock > me? > > > >> > > > > > >> > > BIGTOP-2025 > > > >> > > BIGTOP-2051 > > > >> > > > > > >> > > Thank you very much! > > > >> > > Cos > > > >> > > > > > >> > > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote: > > > >> > > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote: > > > >> > > > > Sorry, I haven't followed the initial discussion since I > was not > > > >> > > onboard at that time. > > > >> > > > > > > > >> > > > > From my view bigtop is the fastest moving project, I ever > knew. I > > > >> am > > > >> > > active > > > >> > > > > for over 20 years in all kinds of opensource projects, but > bigtops > > > >> > > tops them > > > >> > > > > all in speed, second fastest maybe samba and linux kernel > at 0.0x > > > >> > > > > > > >> > > > That's so good to hear! Made my day, if not the whole week! > Speaks > > > >> tons > > > >> > > about > > > >> > > > the community we have on this project! > > > >> > > > > > > >> > > > > I am strongly oppose [i.e. -1] the CTR style, since I think > the > > > >> > > project -- > > > >> > > > > and myself -- take large benefits from discussions about > > > >> implementing > > > >> > > the > > > >> > > > > best solution for the project. > > > >> > > > > > > >> > > > I think CTR doesn't mean that one can not ever ask for a code > review > > > >> > > upfront. > > > >> > > > It's all about trusting the developers to do what's the best > for the > > > >> > > project > > > >> > > > without hanging out high and dry in some obvious cases. > > > >> > > > > > > >> > > > > Getting a +1 is not only that a patch simply runs, it is > about > > > >> code > > > >> > > style, > > > >> > > > > architectural decisions. Even a one-liner patch can break > > > >> designs. > > > >> > > > > > > >> > > > And that again falls back to the point of trusting the > judgement of > > > >> your > > > >> > > peers > > > >> > > > to do the "right thing" and come forward with the discussion > before > > > >> > > making the > > > >> > > > changes that are questionable or contraversial. And we won't > know > > > >> if it > > > >> > > works > > > >> > > > before we try it at least for some time ;) > > > >> > > > > > > >> > > > Cos > > > >> > > > > > > >> > > > > I think a clear review guideline would help bigtop more > that a > > > >> commit > > > >> > > > > policy change. > > > >> > > > > > > > >> > > > > Olaf > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >
