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 > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > >
