> I have a PR that has been pending since *August*. It’s the subject of 2 > jira’s, and I’d emailed members of the PMC about it several times. It has
Have you emails the dev@ list? Repeatedly. Actually, it isn't a requirement. Perhaps some one told you this mistakenly, but it is not. Here's the list of graduation requirements as of today: https://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator "decentralization of project governance" isn't there and I am not really sure what it means. “Decentralization” was me being polite. From: Konstantin Boudnik <[email protected]> Reply: [email protected] <[email protected]> Date: November 27, 2015 at 9:16:37 PM To: [email protected] <[email protected]> Subject: Re: Trying CTR for the project On Fri, Nov 27, 2015 at 09:02PM, Amos B. Elberg wrote: > I think CTR may be a good idea. > > Considering all the excellent efforts to build community by Moon and others, > I can understand why he has experienced the community in the way he > describes. > > My experience, however, has been different. I’m not sure that community > involvement is either as broad, or as deep, as Moon suggests. Silence is not > the same thing as consensus. It seems that active, regular involvement from > outside the PMC is a very small number of people. CTR doesn't let anyone and his brother to simply commit the code into the VCS. You still have to be a committer on the project to do. In order for a committer to bring in your code into the source tree it has to be reviewed and checked-in from that category. > I have a PR that has been pending since *August*. It’s the subject of 2 > jira’s, and I’d emailed members of the PMC about it several times. It has Have you emails the dev@ list? > an active user base, to whom I provide technical support. It’s been > presented to Spark (and soon, R) user groups. However, as I understand it no > member of the PMC has ever downloaded or tried the code. In fact, no member > of the PMC even looked at the code until the users began tweeting to ask why > the PR had not been accepted yet. PMC (actually PPMC) isn't responsible to look at your or anyone else code: they are all volunteers exactly as you and I are. They can spend their time anyway they are pleased. That said, ignoring a contribution for that long isn't helping to grow the community - that's for sure. > One of the prerequisites to graduate from incubation is decentralization of > project governance. For example, it can’t be that all the code, or > significant code, comes from the PMC. And the PMC members can’t be all or > mostly co-affiliated with each other. Actually, it isn't a requirement. Perhaps some one told you this mistakenly, but it is not. Here's the list of graduation requirements as of today: https://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator "decentralization of project governance" isn't there and I am not really sure what it means. Cos > At this point, anything that would decentralize the project can only help > move it toward graduation. In fact, if graduation is a goal, it seems to be > mandatory. > > CTR sounds like it might help. > > From: moon soo Lee <[email protected]> > Reply: [email protected] <[email protected]> > Date: November 27, 2015 at 8:15:50 PM > To: [email protected] <[email protected]> > Subject: Re: Trying CTR for the project > > Thanks for starting the thread. I was keep an eye on discussion about > CTR/RTC on the general@incubator. > > I saw people think RTC means lack of trust in that discussion. To me that > is complete nonsense. I can say, RTC trust others more, trust reviewer. So > I don't agree the "reason" CTR over RTC in the discussion on > general@incubator. > > Importantly, Zeppelin project used to count not only review from committer > but also review from any contributor. This kind of consensus sharing among > the community may be lost or weaken when committers start commit in CTR > fashion. > > But what I agree is, CTR can be faster than RTC. That can help speed up the > development of Zeppelin and that's what I personally really want and can't > wait. > > So, to me, applying CTR for this reason is more than welcome. But I think > we need some preparation to keep the consensus in the community. > > I think building set of guidelines for each components (GUI / Core / > Interpreter / Notebook Storage / etc) would help. Contribution guide that > we're discussing on mailing list [1] and "Zeppelin UI design principle" [2] > could be example, what guidelines trying to do. Community can discuss and > create/change guidelines. > > Once they're settled then I think there will be no big problem applying CTR > in Zeppelin project. And that means some type of discussion about the code > is going to be moved from individual pullrequest to guidelines. Which is > indirect but more scalable way. > > Best, > moon > > [1] http://s.apache.org/ma4 > [2] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328042 > > > On Sat, Nov 28, 2015 at 8:05 AM Konstantin Boudnik <[email protected]> wrote: > > > Guys, > > > > as you might have seen on the general@incubator list, there's a lengthy > > discussion about benefits of Commit-Then-Review (CTR) development model > > over > > Review-Then-Commit (RTC) one. > > > > As the project is getting more mature, I would like to start the > > conversation > > on what the community think about this sort of thing. If anyone isn't clear > > > > about the topic - please chime in and I would be happy to go into as much > > details as needed. In the meanwhile, here a coupe of links that might help > > > > Apache Ignite CTR vs RTC discussion (Ignite is CTR project) > > http://s.apache.org/wPA > > Apache Bigtop CTR vs RTC long thread (Bigtop is a CTR project as well) > > http://is.gd/TgBovX > > > > Regards, > > Cos > >
