+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/225dddcfc78f39bbb296a0d2bbef1caf37e17677c7e5573f0b6fe253@%3Cdev.beam.apache.org%3E >> >> >> >> < >> https://lists.apache.org/thread.html/225dddcfc78f39bbb296a0d2bbef1caf37e17677c7e5573f0b6fe253@%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 >> > >
