All said and done we had enough discussion on this point for many months now. As far as I know, 208 is the PR which community/people have so far used mostly and successfully (at least me and whoever I introduced to 208 for SparkR support). I thought it was going to be merged a long time ago. May be what will make sense is to first integrate the 208. After that, a new PR can be created on that and if 702 has anything extra then that feature can be added.
Regards, Sourav On Mon, Mar 28, 2016 at 12:37 AM, Eran Witkon <eranwit...@gmail.com> wrote: > @Elberg, If I were you I would ask myself why isn't the community taking > part in this debate? > Personally I prefer a team player as a contributor over the best developer. > just my 2c > Eran > > On Mon, 28 Mar 2016 at 09:52 Amos B. Elberg <amos.elb...@gmail.com> wrote: > > > Moon - I opened this discussion so it could take place with the community > > as a whole, not just you. > > > > Suffice it to say, I disagree with every one of the technical claims > > you've just made, and I don't trust your intent. > > > > Let the community process happen. > > > > > On Mar 28, 2016, at 2:47 AM, moon soo Lee <m...@apache.org> wrote: > > > > > > Hi, > > > > > > Simply put, > > > > > > - 702 and/or 208 will can merged as they're ready. [1] > > > - 208 will not be merged while it does not pass CI. If you think code > in > > > 208 is not a problem but CI itself or other part of Zeppelin is > problem, > > > then that particular problem be fixed before merge 208. > > > - 702 has proper integration test [2] > > > > > > I'm not sure why you're so hard at devaluating 702. > > > 702 is not something you need to beat and win. 702 is something you > need > > to > > > help / learn / collaborate. > > > > > > Will you able to show your ability to collaborate with other community > > > members? > > > > > > Thanks, > > > moon > > > > > > [1] > > > > > > http://apache-zeppelin-incubating-dev-mailing-list.75694.x6.nabble.com/R-interpreter-in-Zeppelin-further-steps-tp6967.html > > > [2] > > > > > > https://github.com/apache/incubator-zeppelin/pull/702/files#diff-64a9440e811c5fba6ac1b61157fa6912R87 > > > > > > > > >> On Sun, Mar 27, 2016 at 7:11 PM Amos Elberg <amos.elb...@gmail.com> > > wrote: > > >> > > >> I am saddened to have to start this thread *again*. While I thought > we > > had > > >> reached consensus on this, several times over, apparently some people > > >> disagree. I hope this will be the last time. > > >> > > >> With this thread, I am asking the community to reach consensus (1) > That > > 208 > > >> should be merged this week, without further delay; and (2) That Moon > Lee > > >> Soo and Felix Cheung take no further part in the discussions of 208 > and > > >> 702. > > >> > > >> This PR has been pending since August. It has been stalled that entire > > time > > >> for no technical reason. > > >> > > >> We reached agreement to merge 208 in November, again in December, and > > again > > >> in February -- when Moon agreed to stay out of the issue. At that > > point, > > >> Alex, I, and others, began working on it, and appeared to be making > > >> substantial progress. > > >> > > >> And then Alex just stopped. Instead, he commenced the thread saying > > that a > > >> consensus had to be reached on 208 and 702. Until that point, > > essentially > > >> no-one had paid attention to 702. In the discussion that followed, we > > >> reached a consensus to merge 208 as soon as possible. After the > thread > > had > > >> died, Alex asked if anyone had additional comments, and Moon popped-in > > to > > >> insist that both PRs be merged. Again, no-one supported 702. At all. > > >> > > >> Each time I said "we had a consensus before, does anyone want to > change > > >> it," Alex or Moon steered the discussion away. The final vote was not > > to > > >> merge 702 or merge "both" -- it was to treat them as normal PRs. > > (Although > > >> one person did want both merged simultaneously.) That would mean > > >> completing 208 on its merits and then evaluating 702. > > >> > > >> At the time, I objected to the discussion, because I thought the whole > > >> thing was a contrived excuse for Moon to reject 208 by pushing 702. > > That > > >> is exactly what he is now seeking to do. > > >> > > >> *Status of 208 & 702* > > >> > > >> PR 208 has been feature-complete and testable since early September. > It > > >> has been adopted by more than 1000 users, who I have been supporting > for > > >> more than six months. The code has not undergone any major changes > > since > > >> September. There are no known bugs, and no outstanding feature > requests > > >> that can be satisfied without major changes to the Zeppelin > > architecture. > > >> > > >> 208 does *not* fail CI. 208 includes extensive unit tests of the > > R-Spark > > >> integration because this turned out to get broken by changes in > Zeppelin > > >> often. Because CI is unable at present to provide a consistent > > >> environment, 208's *OWN UNIT TESTS*, which pass when run on an > ordinary > > >> machine, fail when run on CI. > > >> > > >> 208 does need a push for compatibility with a recently adopted PR -- > > that > > >> is work I've essentially completed, but have not pushed. > > >> > > >> PR 702 is a re-design based on 208 -- not just architecture, but right > > down > > >> to the choice of demo images, which were taken from 208's > documentation. > > >> In fact, 702 has had been re-engineered several times to more closely > > >> conform to 208's architecture and feature set. But 702 still remains > > >> feature-incomplete -- it cannot handle the range of visualizations, R > > >> classes, etc., that 208 can. It is not stable code, and shows no signs > > of > > >> stabilizing any time soon. > > >> > > >> No-one has adopted 702. It has changed radically, fundamentally, at > > least > > >> 4 times over the past two months since it was submitted. One of those > > >> changes was only days ago. > > >> > > >> 702 also has no proper tests, which is the excuse for not merging 208. > > 702 > > >> has things labelled "tests," but they don't actually attempt to > connect > > to > > >> R or Spark, which are the things that break and which therefore need > > >> testing. > > >> > > >> *** > > >> > > >> I would like credit for my own work and design. I think I have more > than > > >> earned that. > > >> > > >
