+1 On Thu, Nov 30, 2017 at 8:48 AM, tarush grover <tarushappt...@gmail.com> wrote:
> +1 (binding). > > On Thu, 30 Nov 2017 at 2:06 AM, Eugene Kirpichov <kirpic...@google.com> > wrote: > >> +1 (binding). >> >> I also think that the process here was handled in an acceptable fashion. >> Due to the way our infrastructure works, merging to master was required in >> order to gather essential information for a vote. Though I suppose we >> probably could have had an additional vote about whether or not we should >> even gather the information for the main vote. >> >> Regarding consensus - indeed the consensus on this issue is not >> unanimous, but from my observation the concerns of all sides have been >> heard and addressed by due diligence, even though the disagreement persists >> - which is really all one can reasonably ask for in a large community: I >> think the discussion did reach a point where a vote is the right next step >> to make a decision. >> >> On Wed, Nov 29, 2017 at 10:19 AM Lukasz Cwik <lc...@google.com> wrote: >> >>> I have to disagree about comments about process since in order: >>> * there was a discussion thread before any POCs were created where >>> Gradle and Bazel were brought up >>> * a PR was created that was brought up on dev@ and available to anyone >>> for comment >>> * on the discussion thread it was specifically brought up that empirical >>> evidence was needed by Ken and Romain before a meaningful vote could be had >>> * PR was merged on to master because testing infrastructure is heavily >>> tied to the master branch because of https://issues.apache.org/ >>> jira/browse/BEAM-3047 and https://issues.apache.org/ >>> jira/browse/BEAM-3120. Also the PR specifically said it was to compare >>> Maven/Gradle as described in the PR and using Jenkins was valuable since >>> the information would be public and reproducible. >>> * and now there is this vote thread >>> >>> On Wed, Nov 29, 2017 at 10:02 AM, Robert Bradshaw <rober...@google.com> >>> wrote: >>> >>>> +1 (binding) >>>> >>>> I agree with what both JB and Reuven had to say about process. >>>> >>>> On Wed, Nov 29, 2017 at 7:45 AM, Jean-Baptiste Onofré <j...@nanthrax.net> >>>> wrote: >>>> > Hi Reuven, >>>> > >>>> > I know that the merge was not malicious. No problem at all ;) >>>> > >>>> > It's just about the community and consensus. >>>> > >>>> > For instance, I did discussion + vote to have a consensus about Spark >>>> 2 >>>> > support & upgrade. >>>> > It's not a big deal, but we have to be careful with our communities >>>> (here >>>> > the dev community, for the release schedule/cycle it's more our user >>>> > community ;)). >>>> > >>>> > Thanks, >>>> > Regards >>>> > JB >>>> > >>>> > On 11/29/2017 04:33 PM, Reuven Lax wrote: >>>> >> >>>> >> Thanks for bringing this up JB. >>>> >> >>>> >> I don't think the merge to master was done maliciously. We don't >>>> usually >>>> >> vote before merging PRs, and since that PR did not affect the normal >>>> build >>>> >> process. It was done to gather data about how well Gradle works, not >>>> to >>>> >> force any one outcome (one possible result of the data could have >>>> been that >>>> >> Gradle was slower), I can see how it wasn't obvious that we needed >>>> to vote >>>> >> before merging. >>>> >> >>>> >> However I also see how merging Gradle to master created the >>>> perception >>>> >> that some people were trying to force the issue forward without a >>>> vote, and >>>> >> perceptions like that can be damaging to community (regardless of >>>> good >>>> >> intentions). It's good we're voting now, and let's be more careful >>>> about >>>> >> such things in the future. >>>> >> >>>> >> Reuven >>>> >> >>>> >> On Wed, Nov 29, 2017 at 12:44 AM, Jean-Baptiste Onofré < >>>> j...@nanthrax.net >>>> >> <mailto:j...@nanthrax.net>> wrote: >>>> >> >>>> >> -0 >>>> >> >>>> >> It's not for the change itself (gradle build is interesting) but >>>> for >>>> >> the >>>> >> process used here, which, IMHO, is not clean. >>>> >> >>>> >> My major concern is the fact that gradle build has been merged on >>>> >> master >>>> >> before the vote. I would have start the vote based on the >>>> discussion >>>> >> and PR >>>> >> branch (acting as a PoC). >>>> >> >>>> >> I have the feeling that part of the dev community already >>>> decided to >>>> >> change >>>> >> to gradle and pushed without waiting for the whole consensus. >>>> >> >>>> >> I don't want to "block" this change, but I wanted to raise my >>>> concern >>>> >> from a >>>> >> community standpoint. >>>> >> >>>> >> Regards >>>> >> JB >>>> >> >>>> >> >>>> >> On 11/28/2017 06:55 PM, Lukasz Cwik wrote: >>>> >> >>>> >> This is a procedural vote for migrating to use Gradle for >>>> all our >>>> >> development related processes (building, testing, and >>>> releasing). >>>> >> A >>>> >> majority vote will signal that: >>>> >> * Gradle build files will be supported and maintained >>>> alongside >>>> >> any >>>> >> remaining Maven files. >>>> >> * Once Gradle is able to replace Maven in a specific process >>>> (or >>>> >> portion >>>> >> thereof), Maven will no longer be maintained for said >>>> process (or >>>> >> portion thereof) and will be removed. >>>> >> >>>> >> +1 I support the process change >>>> >> 0 I am indifferent to the process change >>>> >> -1 I would like to remain with our current processes >>>> >> >>>> >> >>>> >> ------------------------------------------------------------ >>>> ---------------------------------------- >>>> >> >>>> >> Below is a summary of information contained in the disucssion >>>> >> thread >>>> >> comparing Gradle and Maven: >>>> >> >>>> >> https://lists.apache.org/thread.html/225dddcfc78f39bbb296a0d2bbef1c >>>> af37e17677c7e5573f0b6fe253@%3Cdev.beam.apache.org%3E >>>> >> >>>> >> <https://lists.apache.org/thread.html/225dddcfc78f39bbb296a0d2bbef1c >>>> af37e17677c7e5573f0b6fe253@%3Cdev.beam.apache.org%3E> >>>> >> >>>> >> Gradle (mins) >>>> >> min: 25.04 >>>> >> max: 160.14 >>>> >> median: 45.78 >>>> >> average: 52.19 >>>> >> stdev: 30.80 >>>> >> >>>> >> Maven (mins) >>>> >> min: 56.86 >>>> >> max: 216.55 (actually > 240 mins because this data does not >>>> >> include >>>> >> timeouts) >>>> >> median: 87.93 >>>> >> average: 109.10 >>>> >> stdev: 48.01 >>>> >> >>>> >> Maven >>>> >> Java Support: Mature >>>> >> Python Support: None (via mvn exec plugin) >>>> >> Go Support: Rudimentary (via mvn plugin) >>>> >> Protobuf Support: Rudimentary (via mvn plugin) >>>> >> Docker Support: Rudimentary (via mvn plugin) >>>> >> ASF Release Automation: Mature >>>> >> Jenkins Support: Mature >>>> >> Configuration Language: XML >>>> >> Multiple Java Versions: Yes >>>> >> Static Analysis Tools: Some >>>> >> ASF Release Audit Tool (RAT): Rudimentary (plugin complete >>>> and >>>> >> longstanding but poor) >>>> >> IntelliJ Integration: Mature >>>> >> Eclipse Integration: Mature >>>> >> Extensibility: Mature (updated per JB from discuss thread) >>>> >> Number of GitHub Projects Using It: 146k >>>> >> Continuous build daemon: None >>>> >> Incremental build support: None (note that this is not the >>>> same as >>>> >> incremental compile support offered by the compiler plugin) >>>> >> Intra-module dependencies: Rudimentary (requires the use of >>>> many >>>> >> profiles to get per runner dependencies) >>>> >> >>>> >> Gradle >>>> >> Java Support: Mature >>>> >> Python Support: Rudimentary (pygradle, lacks pypi support) >>>> >> Go Support: Rudimentary (gogradle plugin) >>>> >> Protobuf Support: Rudimentary (via protobuf plugin) >>>> >> Docker Support: Rudimentary (via docker plugin) >>>> >> ASF Release Automation: ? >>>> >> Jenkins Support: Mature >>>> >> Configuration Language: Groovy >>>> >> Multiple Java Versions: Yes >>>> >> Static Analysis Tools: Some >>>> >> ASF Release Audit Tool (RAT): Rudimentary (plugin just calls >>>> >> Apache >>>> >> Maven ANT plugin) >>>> >> IntelliJ Integration: Mature >>>> >> Eclipse Integration: Mature >>>> >> Extensibility: Mature >>>> >> Number of GitHub Projects Using It: 122k >>>> >> Continuous build daemon: Mature >>>> >> Incremental build support: Mature >>>> >> Intra-module dependencies: Mature (via configurations) >>>> >> >>>> >> >>>> >> -- Jean-Baptiste Onofré >>>> >> jbono...@apache.org <mailto:jbono...@apache.org> >>>> >> http://blog.nanthrax.net >>>> >> Talend - http://www.talend.com >>>> >> >>>> >> >>>> > >>>> > -- >>>> > Jean-Baptiste Onofré >>>> > jbono...@apache.org >>>> > http://blog.nanthrax.net >>>> > Talend - http://www.talend.com >>>> >>> >>>
