On Thu, Dec 3, 2015 at 4:54 AM Konstantin Boudnik <[email protected]> wrote:
> On Wed, Dec 02, 2015 at 01:17PM, Amos B. Elberg wrote: > > Moon — I think there is a misunderstanding about the topic of the > discussion. > > > > The PR has its own userbase. It has been and is being presented at user > > groups. Its been blogged and tweeted about (none of that came from me!) > > The features are the subject of two jiras and on the Zeppelin roadmap. > So, > > the discussion isn't about whether the PR is “good." > > We aren't talking about the user-base or who sent what twits. Moreover, > statements about the project's road map should only be made by the > community > working on the project. 3rd party opinions are irrelevant, unless said > party > is contributing something. You might be familiar with "Words are cheap, > show > me the code" saying. Apache is a do-ocracy: actions (ie the contributions) > speak louder than anything else. > > > But no-one responded to the PR until users began to tweet publicly > @nflabs > > asking why the PR had not been adopted, and e-mailing you directly. This > > looks really bad, especially when the project is considering applying to > > leave incubation. > > This is one of the things that worries me dearly. So, let's figure out how > to > make sure that PRs aren't sitting there for three months. > I am not really interested in who said what where. I intend to give people > a benefit of the doubt and not interpret their actions as hostile or > intentionally bad, unless I have evidence of such. > > Cos > Thanks Cos, Following is one of the reasons for some PRs that they're sitting there, 1. Contributor opens a pullrequest, 2. Have discussions and decided add some commit, 3. Contributor adds more commits into pullrequest 4. Contributor wait for a review. 5. But committer does respond anymore. I received direct email message about 5) from different contributors couple of times. I think it happens when committer does not regularly check pullrequest while 3) does not generate any automatic notification. But checking every pullrequest manually is not practically possible, especially when the pullrequest is not in active discussion. So guide contributor, always leave a comment such as "review this", "ready to review" after adding commit would improve one more case that make contribution impasse. I'd like to learn how the other project who uses github pullrequest deal this problem. Thanks, moon > > The question here is what, if anything, prevents us from letting bygones > be > > bygones and moving forward with this now? > > > > Claims about CI issues, or licenses, or the PR shouldn’t have been > rebased > > (!?!) — well, they don’t really make sense. > > > > I keep offering to begin coordinating to integrate the PR with > Zeppelin’s CI > > and build system. > > > > But the answer (except from Roman) is still “nah, let us know if you > figure > > it out.” > > > > Regarding the history: > > > > Konstantin wisely started this thread by saying let’s keep the history > out > > of the discussion. I am respecting that. > > > > If the PR becomes part of Zeppelin, its going to need to be maintained, > > which means that we are going to need to be able to work together. > > > > I have been persuaded to give Moon the benefit of the doubt regarding > > certain issues. He certainly knows what my view of the history is. > > > > If anyone else would like to know, I am happy to share it with them > off-list. > > > > > > From: moon soo Lee <[email protected]> > > Reply: [email protected] < > [email protected]> > > Date: December 2, 2015 at 7:45:11 AM > > To: [email protected] <[email protected] > > > > Subject: Re: contributions impasse. Was: [GitHub] incubator-zeppelin > pull request: R Interpreter for Zeppelin > > > > Thanks Roman and Eran for the feedback. > > > > *A. About contribution impasse in general* > > > > I think i summarized why it happens and how it can be improved. ie. > > > > 1. Large code base change > > 2. Communication lost > > 3. Opinion diverges > > > > And my solution was > > > > Guide to ping other committer when a committer is not responding, divide > > contribution into small peaces if possible. And committer pay more > > attention to the contribution. > > > > I'd like to hear and learn any more idea to improve. > > > > > > *B. About contribution impasses in R interpreter for Zeppelin* > > > > Although I'was the first one who reviewed and commented this contribution > > among the committer, I feel contributor (Amos) is unhappy about the > review. > > > > I want to analyze the reasons and improve this, too. > > > > Here's reason i guess > > > > 1. Late responding (first review has been made after 3 months) > > 2. Lack of help on CI fail (Amos keep complained about CI fail) > > > > I think both 1 and 2 can be improved by the solution i suggested in > section > > A. > > > > Amos, if you think there're more reasons, please feel free to say and let > > me improve. What is the history you're mentioning? > > > > Best, > > moon > > > > > > On Wed, Dec 2, 2015 at 5:44 PM Alexander Bezzubov <[email protected]> > wrote: > > > > > Just pushing discussion back on the list > > > > > > On Wed, Dec 2, 2015, 01:14 Amos B. Elberg <[email protected]> > wrote: > > > > > > > Alex — if you genuinely do not know the history of this, then I will > fill > > > > you in. > > > > > > > > lmk… > > > > > > > > > > > > -- > > > > Amos Elberg > > > > Sent with Airmail > > > > > > > > From: Alexander Bezzubov <[email protected]> <[email protected]> > > > > Reply: Alexander Bezzubov <[email protected]> <[email protected]> > > > > Date: December 1, 2015 at 6:14:20 AM > > > > To: [email protected] < > [email protected] > > > > > > > > <[email protected]>, Amos B. Elberg > > > > <[email protected]> <[email protected]> > > > > > > > > Subject: Re: contributions impasse. Was: [GitHub] incubator-zeppelin > > > > pull request: R Interpreter for Zeppelin > > > > > > > > @Amos, we had plenty of cases of CI failing and always the > pre-condition > > > > for a merge was a green CI. Sometimes that requires time, polite > > > > collaboration, extra mile in direct asking for help from more > experienced > > > > members and fixes in different places, which indeed might take time, > as > > > > everyone is busy. > > > > > > > > > > > >
