Vote concluded with: 16: +1 (4 binding) 1: -0 (1 binding) 1: -1 (0 binding)
Committers/PMC, please ensure that changes to Maven pom's are correspondingly seen in Gradle build files as well. Next steps are to flesh out the details on migration in https://issues.apache.org/jira/browse/BEAM-3249. On Wed, Nov 29, 2017 at 6:19 PM, Pei HE <p...@apache.org> wrote: > +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/225dddcfc78f39bbb296a0d >>>>> 2bbef1caf37e17677c7e5573f0b6fe253@%3Cdev.beam.apache.org%3E >>>>> >> >>>>> >> <https://lists.apache.org/thread.html/225dddcfc78f39bbb296a0 >>>>> d2bbef1caf37e17677c7e5573f0b6fe253@%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 >>>>> >>>> >>>> >