Alex: I believe I have repeatedly explained why C is not meritocratic, and not good for anybody. In fact, it would only make worse the problem that many users have complained about -- confusion created by the presence of 702. I do not believe I should have to repeat myself *again*.
> Please correct me if I'm wrong, but at this poit one can see only one > strong -1 for going on with plan C. You're wrong. No-one has advocated for C. You actually (apparently) want B. Moreover, no-one has given any justification for C or, for that matter, B. Continuing this discussion, when there has been a consensus in favor of A all along, is inconsistent with the management of an Apache project. Moreover, it is dishonest. If we are going to continue this discussion --- please put forward a simple, clear explanation of what in 702 leads you -- or anyone -- to think that including 702 would add anything to Zeppelin at all, if 208 is merged. On Tuesday, March 08, 2016 08:11:47 AM Alexander Bezzubov wrote: > Eric, > thank you for chimming in and I'm sorry for miss-information on 702! > > To be honest, I totally agree on your point on B. That would be the best of > all worlds, but given the time and input from other participants the > concensus over B seems to be hard to reach. I would love to contribute in > B, but if its not possible, C sounds like a way to go to me. > > Please correct me if I'm wrong, but at this poit one can see only one > strong -1 for going on with plan C. > > I want to ask Amos to give > - the concise gist of why he thinks plan C is not a good meritocratic > solution for everybody (without mentioning any other people, please) > - and what is the compromiss he suggests, given what the community have > spoken out > > -- > Alex > > On Tue, Mar 8, 2016, 16:21 Eric Charles <e...@apache.org> wrote: > > Small precisions on #702: > > > > (snip...) > > > > > - 702 > > > > > > * CI fails > > > > Just pushed and it is failing for non R related reasons... > > > > Most importantly, I have seen since a few days that the test are no more > > executed for the spark interpreter for all PR builds > > > > [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ > > zeppelin-spark --- > > [INFO] Tests are skipped. > > > > Will have a look at it. > > > > > * no tests > > > > There is some test > > > > > > https://github.com/datalayer/zeppelin-datalayer/blob/rscala-z/spark/src/te > > st/java/org/apache/zeppelin/spark/SparkRInterpreterTest.java> > > > * no docs > > > > There is some doc > > > > > > https://github.com/datalayer/zeppelin-datalayer/blob/rscala-z/docs/interpr > > eter/R.md> > > > That being said, my personal opinion is that we should follow C, and > > > #208 > > > there has more chances of being merged first. > > > > > > Again, the goal is not to compare both contributions in terms of > > > features/merit and decide here which is better, but to build a consensus > > > > on > > > > > how we as a community proceed in situation of two contributions of same > > > pluggable feature. In this thread, it means to have no -1s for for at > > > > least > > > > > one option, though a thoughtful compromise from all sides. > > > > > > What do you guys think? > > > > I would favor b) but this may take too much time, so to get users the > > best choice as soon as possible, c) sounds to me like the way to go. > > > > > With PPMC hat on, I feel that we may need to start a separate thread for > > > > a > > > > > generalised decidion-making process in such situation, irrigating of > > > current state of issue with R interpreter. And after a making a decision > > > there, we could use the same guiding principle to resolve this issue, as > > > well as any other one in the future. > > > > > > > > > > > > -- > > > Alex > > > > > > On Tue, Mar 8, 2016 at 2:45 PM, Jeff Steinmetz < > > > > jeffrey.steinm...@gmail.com> > > > > > wrote: > > >> I should clarify my preference regarding Plan A (to only merge 1 - at > > >> least initially). > > >> “Which” PR to merge (or merge first) is TBD - at least for myself. I’m > > >> still testing both PR options. > > >> Since the original request was not to debate the fate\merit\features of > > >> any particular contribution in this thread, I’ll post my 702 PR > > >> findings > > >> separately. > > >> > > >> > > >> > > >> ---- > > >> Jeff Steinmetz > > >> Principal Architect > > >> Akili Interactive > > >> www.akiliinteractive.com <http://www.akiliinteractive.com/> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On 3/2/16, 9:12 PM, "Jeff Steinmetz" <jeffrey.steinm...@gmail.com> > > > > wrote: > > >>> I too prefer plan A - merging two different R interpreters sounds like > > > > a > > > > >> maintenance and documentation headache for end users. > > >> > > >>> Do you or the community feel there are “specific” additional steps > > > > from a > > > > >> “technical” or “development” perspective that need to happen in order > > > > merge > > > > >> 208? > > >> > > >>> If we know what’s holding back the merge technically (all history > > > > aside) > > > > >> we can work as a community to solve it. > > >> > > >>> Olympic spirit! > > >>> Looking forward to helping this through. > > >>> > > >>> ---- > > >>> Jeff Steinmetz > > >>> Principal Architect > > >>> Akili Interactive > > >>> > > >>> On 3/2/16, 8:14 PM, "Amos Elberg" <amos.elb...@gmail.com> wrote: > > >>>> Alex -- the gist of my email is that we already have a consensus, and > > >> > > >> have had > > >> > > >>>> a consensus since November. The consensus was to merge 208. That's > > >> > > >> "Plan A." > > >> > > >>>> With all respect, I don't see that anyone other than you believes we > > >> > > >> don't > > >> > > >>>> have a consensus on Plan A already, or has any issue with Plan A. > > >>>> > > >>>> In fact, I'm going to call now for "lazy consensus" on Plan A: End > > > > the > > > > >> debate > > >> > > >>>> and move rapidly to merge 208, completing whatever work is necessary > > > > to > > > > >> do > > >> > > >>>> that (if any). > > >>>> > > >>>> For the record, yes, I do object to Plan C. Numerous users have > > >> > > >> complained > > >> > > >>>> that with two different PRs, they don't know which interpreter to > > >>>> use. > > >> > > >> That's > > >> > > >>>> a strong reason to not merge two. In fact it will confuse people > > >>>> more, > > >> > > >> because > > >> > > >>>> one interpreter's R environment won't be shared with the other > > >> > > >> interpreter, > > >> > > >>>> and you can't move variables between them. Moreover, no-one has > > >> > > >> presented any > > >> > > >>>> benefit to merging the second one. > > >>>> > > >>>> In addition, while 208 seems to be ready to merge (waiting only on > > >>>> the > > >> > > >> work > > >> > > >>>> you're doing on CI), the second PR is nowhere close. So, that's > > > > another > > > > >>>> reason: 208 should not have to wait for the other to be ready. > > >>>> > > >>>> But in any event, I disagree that there is any issue here. > > >>>> > > >>>> If you intend to continue this thread, then please address the issues > > >> > > >> raised > > >> > > >>>> in my e-mail earlier. Please also explain any strong objection to > > > > Plan > > > > >> A. > > >> > > >>>> Thanks, > > >>>> > > >>>> -Amos > > >>>> > > >>>> On Thursday, March 03, 2016 12:09:33 PM Alexander Bezzubov wrote: > > >>>>> Guys, please let's keep the discussion focused on the subject. > > >>>>> > > >>>>> Amos, I do not understand, are you saying that you do object on the > > >>>>> community proceeding with plan C? If not - there is no need to > > >> > > >> answer\post > > >> > > >>>>> in this thread right now. > > >>>>> > > >>>>> Again, we are not debating fate\merit\features of any particular > > >>>>> contribution here. > > >>>>> > > >>>>> Please post in this thread only if you strongly disagree with the > > >> > > >> suggested > > >> > > >>>>> plan. > > >>>>> I'm calling for a lazy consensus and as soon as there are no > > >> > > >> objections - > > >> > > >>>>> will be ready to proceed with the plan above. > > >>>>> > > >>>>> Sooner we reach a consensus on the topic - sooner we can make > > >>>>> further > > >>>>> progress. > > >>>>> > > >>>>> -- > > >>>>> Alex > > >>>>> > > >>>>> On Thu, Mar 3, 2016 at 11:45 AM, Amos Elberg <amos.elb...@gmail.com> > > >> > > >> wrote: > > >>>>>> Alex - What are we still debating at this point? > > >>>>>> > > >>>>>> I'm starting to feel like Charlie Brown with the football here. > > >>>>>> > > >>>>>> The PR was submitted in August and originally reviewed at the > > >> > > >> beginning of > > >> > > >>>>>> September. > > >>>>>> In, I think, early December, it was then extensively reviewed and > > >>>>>> discussed. I made a few requested changes, and at that time there > > >> > > >> was a > > >> > > >>>>>> decision to merge 208 pending Moon working on the CI problem. > > >>>>>> In January the PR was reviewed again, by you and others, and I > > >> > > >> thought > > >> > > >>>>>> you'd decided to merge pending some changes from me, and you were > > >> > > >> going to > > >> > > >>>>>> work on CI. > > >>>>>> In February, when people continued to email the list to ask what > > >>>>>> was > > >> > > >> up, > > >> > > >>>>>> we > > >>>>>> said again that the community was moving to merge 208. > > >>>>>> The thread started a few days ago. Nobody argued for changing the > > >> > > >> plan. > > >> > > >>>>>> The discussion lapsed until, today, I responded to a technical > > > > point. > > > > >>>>>> I'm not sure why this is coming up again. If Eric (or others) feel > > >>>>>> strongly about the issues Eric raised with 208, which is things > > >>>>>> like > > >>>>>> whether to link rscala or fork it (or whatever), why can't they > > >>>>>> just > > >>>>>> submit > > >>>>>> PRs with those change after 208 is merged? The architectures of > > >>>>>> the > > >> > > >> two > > >> > > >>>>>> PRs have been converging as Eric's been incorporating > > >>>>>> functionality. > > >>>>>> No-one claims that Eric's interpreter provides any additional > > >>>>>> functionality, or that its more stable, or anything like that. So > > >> > > >> why are > > >> > > >>>>>> we still talking about this? > > >>>>>> > > >>>>>> If the issue is that Eric put in substantial work, that was a > > >>>>>> choice > > >> > > >> he > > >> > > >>>>>> made after he knew the status of 208. He also had the benefit of > > >> > > >> seeing > > >> > > >>>>>> how I solved various technical problems, like using rscala, sharing > > >> > > >> the > > >> > > >>>>>> Spark Context, etc. In fact, when I first started on this project, > > >> > > >> I saw > > >> > > >>>>>> that Eric had done some preliminary work, and wrote him to see if > > >>>>>> we > > >> > > >> could > > >> > > >>>>>> collaborate. He wasn't interested. In November, when I heard that > > >>>>>> Datalayer had produced an interpreter (I didn't realize Datalayer > > >>>>>> is > > >> > > >> Eric) > > >> > > >>>>>> I wrote them offering to work together. No reply. And in > > >>>>>> December > > >> > > >> also. > > >> > > >>>>>> No reply. Eric didn't even submit the PR until after there was > > >> > > >> already a > > >> > > >>>>>> consensus to merge 208. His PR only started to approach feature > > >> > > >> parity in > > >> > > >>>>>> the last few weeks, after we decided *again* to try to merge 208. > > >>>>>> > > >>>>>> Someone commented earlier in this thread that we need to get this > > >> > > >> resolved > > >> > > >>>>>> so the community can move on. I agree. I want to move on also. > > >>>>>> > > >>>>>> Is there any substantial reason at this point why we're revisiting > > >> > > >> the > > >> > > >>>>>> issue instead of simply trying to merge 208? Is there any reason > > >> > > >> not to > > >> > > >>>>>> view the discussion in this email chain as resolved in favor of > > >> > > >> merging > > >> > > >>>>>> 208 > > >>>>>> and moving forward? Is there anything you're waiting on me for > > >>>>>> that > > >> > > >> you > > >> > > >>>>>> need so 208 can get merged? What, at this point, is left to be > > >>>>>> done > > >> > > >> so > > >> > > >>>>>> 208 > > >>>>>> can be merged? > > >>>>>> > > >>>>>> On Wed, Mar 2, 2016 at 7:53 PM, Alexander Bezzubov <b...@apache.org> > > >> > > >> wrote: > > >>>>>>> Thank you guys for actually answering the question! > > >>>>>>> > > >>>>>>> My personal opinion on making a progress here, and in further > > >> > > >> cases like > > >> > > >>>>>>> that, lies with a plan C. > > >>>>>>> > > >>>>>>> Please correct me if I'm wrong, but what I can see in this thread > > >> > > >> is a > > >> > > >>>>>>> consensus around going further with plan C: merging contribution > > >> > > >> as soon > > >> > > >>>>>> as > > >>>>>> > > >>>>>>> it is ready, without the need to block another contributions (as > > >> > > >> they > > >> > > >>>>>> have > > >>>>>> > > >>>>>>> technical merit, of course) and let actual users decide. > > >>>>>>> > > >>>>>>> At this point, I'd really love to hear only from people that > > >> > > >> disagree > > >> > > >>>>>> with > > >>>>>> > > >>>>>>> above and have strong opinions about that or think that the > > >> > > >> concerns > > >> > > >>>>>>> they > > >>>>>>> have raised before were not addressed properly. > > >>>>>>> > > >>>>>>> Thanks again, > > >>>>>>> I really appreciate everyone's time, spent on this issue. > > >>>>>>> > > >>>>>>> -- > > >>>>>>> Alex > > >>>>>>> > > >>>>>>> > > >>>>>>> On Tue, Mar 1, 2016 at 1:02 PM, Jeff Steinmetz < > > >>>>>>> jeffrey.steinm...@gmail.com> > > >>>>>>> > > >>>>>>> wrote: > > >>>>>>>> I too was able to use R via PR 208 with success. > > >>>>>>>> > > >>>>>>>> I have it running as expected within the Virtual Machine > > >> > > >> outlined in > > >> > > >>>>>> this > > >>>>>> > > >>>>>>>> updated PR > > >>>>>>>> https://github.com/apache/incubator-zeppelin/pull/751/ > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> With the `repl` package (also installed via the VM script), > > >> > > >> plotting > > >> > > >>>>>> such > > >>>>>> > > >>>>>>>> as native R histograms worked within the notebook display system > > >> > > >> as > > >> > > >>>>>> well. > > >>>>>> > > >>>>>>>> So - this looks good to me. > > >>>>>>>> > > >>>>>>>> Not to oversimplify things, it “seems” this PR (or this PR and a > > >>>>>>>> future > > >>>>>>> > > >>>>>>> PR > > >>>>>>> > > >>>>>>>> for packaging) just needs: > > >>>>>>>> - the packaging worked out (get the R scripts included in the > > >>>>>>>> > > >>>>>>>> distribution) > > >>>>>>>> > > >>>>>>>> - a few license additions to the rscala files (if they are not > > >>>>>> > > >>>>>> generated > > >>>>>> > > >>>>>>>> but part of the base requirements) > > >>>>>>>> > > >>>>>>>> - a profile addition such as -P r to only build with R binaries > > >> > > >> if > > >> > > >>>>>>>> desired. > > >>>>>>>> > > >>>>>>>> Unless I am missing something, it could be merged with one final > > >>>>>> > > >>>>>> focused > > >>>>>> > > >>>>>>>> effort. > > >>>>>>>> Somebody could tweak the documentation a bit to match the tone > > >> > > >> of the > > >> > > >>>>>>>> other interpreter docs post merge. > > >>>>>>>> > > >>>>>>>> Regards, > > >>>>>>>> Jeff Steinmetz > > >>>>>>>> Principal Architect > > >>>>>>>> Akili Interactive > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 2/29/16, 6:45 AM, "Sourav Mazumder" < > > >> > > >> sourav.mazumde...@gmail.com> > > >> > > >>>>>>>> wrote: > > >>>>>>>>> Very similar is my experience too. > > >>>>>>>>> > > >>>>>>>>> Could run PR 208 with least effort. And so far I am very > > >> > > >> successful > > >> > > >>>>>>>>> to > > >>>>>>> > > >>>>>>> use > > >>>>>>> > > >>>>>>>>> it to create demonstrations covering end to end machine > > >> > > >> learning use > > >> > > >>>>>>> cases > > >>>>>>> > > >>>>>>>>> in Zeppelin (showcasing how data can be shared across scala, > > >> > > >> SparkR, > > >> > > >>>>>>>>> R > > >>>>>>>>> easily where data preparation/model creation done in > > >> > > >> SparkR/Scala > > >> > > >>>>>> where > > >>>>>> > > >>>>>>> as > > >>>>>>> > > >>>>>>>>> visualization in R) using PR 208 in different meetups and other > > >>>>>> > > >>>>>> forums. > > >>>>>> > > >>>>>>>>> Regards, > > >>>>>>>>> Sourav > > >>>>>>>>> > > >>>>>>>>> On Mon, Feb 29, 2016 at 5:04 AM, enzo < > > >> > > >> e...@smartinsightsfromdata.com > > >> > > >>>>>>>>> wrote: > > >>>>>>>>>> As a keen R user I tried both branches, but I couldn’t make > > >> > > >> work > > >> > > >>>>>>>> Charles' > > >>>>>>>> > > >>>>>>>>>> version (maybe my mistake). I found some issue on Amos' > > >> > > >> version > > >> > > >>>>>>> (mainly > > >>>>>>> > > >>>>>>>>>> about charting), reported on his github page (he has > > >> > > >> suggested to > > >> > > >>>>>> test > > >>>>>> > > >>>>>>>> more > > >>>>>>>> > > >>>>>>>>>> extensively and report after merge - fair enough). > > >>>>>>>>>> > > >>>>>>>>>> In conclusion I do not have sound enough elements to judge on > > >> > > >> which > > >> > > >>>>>>> one > > >>>>>>> > > >>>>>>>> is > > >>>>>>>> > > >>>>>>>>>> better. As I’m in favour of competition as a general > > >> > > >> principle, > > >> > > >>>>>> taking > > >>>>>> > > >>>>>>>> into > > >>>>>>>> > > >>>>>>>>>> account that they seem to be close to the finishing line I > > >> > > >> would > > >> > > >>>>>>>> suggest to > > >>>>>>>> > > >>>>>>>>>> merge each one and let users decide: I concur with Eran. > > >>>>>>>>>> > > >>>>>>>>>> It would be useful (just to avoid similar occurrences in the > > >>>>>>>>>> future) > > >>>>>>> > > >>>>>>> to > > >>>>>>> > > >>>>>>>>>> understand why we arrived here though. How is it possible > > >> > > >> that a > > >> > > >>>>>>>>>> fundamental pr as R interpreter takes so long to be > > >> > > >> integrated? I > > >> > > >>>>>>> would > > >>>>>>> > > >>>>>>>>>> humbly suggest for the future to give better treatment to the > > >> > > >> big > > >> > > >>>>>>>> hitting > > >>>>>>>> > > >>>>>>>>>> functionalities. Clearly the more a ‘big’ functionality is > > >>>>>>>>>> delayed, > > >>>>>>> > > >>>>>>> the > > >>>>>>> > > >>>>>>>>>> more will be deemed attractive to develop alternative versions > > >>>>>>>>>> (some > > >>>>>>>> > > >>>>>>>> time > > >>>>>>>> > > >>>>>>>>>> better versions, some time equally useful). > > >>>>>>>>>> > > >>>>>>>>>> Another consideration is the over present issue of graphics. > > >> > > >> From > > >> > > >>>>>> an > > >>>>>> > > >>>>>>> R > > >>>>>>> > > >>>>>>>>>> standpoint, due to the extreme richness of its graphic > > >> > > >> offering, so > > >> > > >>>>>>> far > > >>>>>>> > > >>>>>>>> I > > >>>>>>>> > > >>>>>>>>>> found that no notebook is entirely satisfactory: for example > > >> > > >> the > > >> > > >>>>>>> growing > > >>>>>>> > > >>>>>>>>>> family of htmlwidgets are badly (or not) displayed in many > > >> > > >> cases. > > >> > > >>>>>>>>>> It > > >>>>>>>> > > >>>>>>>> would > > >>>>>>>> > > >>>>>>>>>> certainly benefit the community to invest time and activities > > >> > > >> on > > >> > > >>>>>>>> perfecting > > >>>>>>>> > > >>>>>>>>>> these issues, but so be it. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Enzo > > >>>>>>>>>> e...@smartinsightsfromdata.com > > >>>>>>>>>> > > >>>>>>>>>>> On 29 Feb 2016, at 12:36, Eran Witkon <eranwit...@gmail.com > > >>>>>> > > >>>>>> wrote: > > >>>>>>>>>>> I think we should ask ourselves what is the guiding > > >> > > >> principle > > >> > > >>>>>> here, > > >>>>>> > > >>>>>>>> for > > >>>>>>>> > > >>>>>>>>>>> example, if in the future I want to create yet another JDBC > > >>>>>>>> > > >>>>>>>> interpreter > > >>>>>>>> > > >>>>>>>>>> or > > >>>>>>>>>> > > >>>>>>>>>>> Flink interpreter, should I only extend the one that already > > >>>>>>>>>>> exist > > >>>>>>> > > >>>>>>> or > > >>>>>>> > > >>>>>>>>>> can I > > >>>>>>>>>> > > >>>>>>>>>>> create my own and let the user community decide? > > >> > > >> realistically I > > >> > > >>>>>>> don't > > >>>>>>> > > >>>>>>>>>>> think we can control where people invest their time and > > >>>>>> > > >>>>>> contribution > > >>>>>> > > >>>>>>>> and > > >>>>>>>> > > >>>>>>>>>> as > > >>>>>>>>>> > > >>>>>>>>>>> long as it has no licencing issues and align with other > > >> > > >> project > > >> > > >>>>>>>> guidance > > >>>>>>>> > > >>>>>>>>>> it > > >>>>>>>>>> > > >>>>>>>>>>> should be up to the users to decide. > > >>>>>>>>>>> > > >>>>>>>>>>> Eran W > > >>>>>>>>>>> > > >>>>>>>>>>> On Mon, Feb 29, 2016 at 2:13 PM DuyHai Doan < > > >> > > >> doanduy...@gmail.com > > >> > > >>>>>>>>>> wrote: > > >>>>>>>>>>>> Hello Alexander > > >>>>>>>>>>>> > > >>>>>>>>>>>> My opinion is no one, unless being an expert with R, is > > >> > > >> able to > > >> > > >>>>>>> judge > > >>>>>>> > > >>>>>>>>>> the > > >>>>>>>>>> > > >>>>>>>>>>>> quality of both contributions apart from the authors > > >> > > >> themselves. > > >> > > >>>>>> So > > >>>>>> > > >>>>>>>>>> let's > > >>>>>>>>>> > > >>>>>>>>>>>> make them work together to merge 2 PR into a good one. > > >> > > >> Those > > >> > > >>>>>>>>>>>> PR, > > >>>>>>>>>>>> especially the #208 has been there for a while and it's > > >> > > >> high > > >> > > >>>>>>>>>>>> time > > >>>>>>>> > > >>>>>>>> they > > >>>>>>>> > > >>>>>>>>>> get > > >>>>>>>>>> > > >>>>>>>>>>>> merged so the community can move on. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Unless there are R experts in the Zeppelin community and > > >> > > >> so they > > >> > > >>>>>>>> should > > >>>>>>>> > > >>>>>>>>>>>> speak to give their own opinions. > > >>>>>>>>>>>> > > >>>>>>>>>>>> My 2 cents > > >>>>>>>>>>>> > > >>>>>>>>>>>> Duy Hai DOAN > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Mon, Feb 29, 2016 at 1:04 PM, Alexander Bezzubov < > > >>>>>>> > > >>>>>>> b...@apache.org> > > >>>>>>> > > >>>>>>>>>>>> wrote: > > >>>>>>>>>>>>> Hi fellow Zeppelin community members, > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> as you know, we have 2 contributions for ZEPPELIN-156 > > >>>>>>>>>>>>> <https://issues.apache.org/jira/browse/ZEPPELIN-156> AKA > > >> > > >> R > > >> > > >>>>>>>>>>>>> <https://github.com/apache/incubator-zeppelin/pull/208> > > >>>>>>> > > >>>>>>> interpreter > > >>>>>>> > > >>>>>>>>>>>>> <https://github.com/apache/incubator-zeppelin/pull/702>. > > >>>>>>>>>>>>> Both have merit, so wearing my PPMC hat, I'd like to > > >> > > >> suggest us > > >> > > >>>>>> to > > >>>>>> > > >>>>>>>>>> make a > > >>>>>>>>>> > > >>>>>>>>>>>>> decision, how we move forward with it avoiding user > > >> > > >> confusion. > > >> > > >>>>>>>>>>>>> Here is what we can do: > > >>>>>>>>>>>>> - a. pick only one of those and merge it > > >>>>>>>>>>>>> - b. ask authors of both of them to collaborate together > > >> > > >> and > > >> > > >>>>>> come > > >>>>>> > > >>>>>>> up > > >>>>>>> > > >>>>>>>>>>>> with > > >>>>>>>>>>>> > > >>>>>>>>>>>>> one > > >>>>>>>>>>>>> - c. merge each, as soon as it's ready and let > > >>>>>>>>>>>>> users\maintainers > > >>>>>>>> > > >>>>>>>> decide > > >>>>>>>> > > >>>>>>>>>>>>> which one is best at the end > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> This is not an official VOTE (which is possible to > > >> > > >> arrange, but > > >> > > >>>>>> is > > >>>>>> > > >>>>>>>>>> rather > > >>>>>>>>>> > > >>>>>>>>>>>>> bad way to build a consensus). > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> It is a discussion, aimed to see if we all, as community, > > >> > > >> can > > >> > > >>>>>>> build > > >>>>>>> > > >>>>>>>> a > > >>>>>>>> > > >>>>>>>>>>>>> consensus together cooperatively - meaning, *everyone > > >>>>>> > > >>>>>> compromises > > >>>>>> > > >>>>>>>>>>>>> something *and* there are no really strong opinions > > >> > > >> against the > > >> > > >>>>>>>> final > > >>>>>>>> > > >>>>>>>>>>>>> plan*. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> I specifically DO NOT ask which one is better, have more > > >>>>>> > > >>>>>> features, > > >>>>>> > > >>>>>>>> etc, > > >>>>>>>> > > >>>>>>>>>>>>> etc, etc. > > >>>>>>>>>>>>> What I ask for are opinions on a community way of > > >> > > >> reconciling > > >> > > >>>>>> this > > >>>>>> > > >>>>>>>>>>>>> situation and moving project forward together. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> What do you think? > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> -- > > >>>>>>>>>>>>> Kind regards, > > >>>>>>>>>>>>> Alexander.
