What I find real good about this experiment is that we don't see any abuse of this policy. Committers are actively seeking the feedback if they feel a need to have a discussion about the implementation. Which is one of the most common objections to the model.
On Tue, Nov 17, 2015 at 02:06PM, Evans Ye wrote: > 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 > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >
signature.asc
Description: Digital signature
