[Starting a new thread to not hijack the voting one...] On Wed, Nov 29, 2017 at 10:19 AM, Lukasz Cwik <[email protected]> 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
I agree with JB in that there may have been a perception that we were switching to Gradle without sufficient community feedback. I agree with Reuven (and you) that the actions were completely reasonable and done with good intent. The only thing I would have done differently (in hindsight!) is been very explicit on the list "we're merging this to gather more data, any objections?" I, personally, don't think that needed a vote, but this would have been a chance for those who felt differently to call for a vote, which would have been respected if anyone felt strongly. - Robert > On Wed, Nov 29, 2017 at 10:02 AM, Robert Bradshaw <[email protected]> > 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é <[email protected]> >> 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é <[email protected] >> >> <mailto:[email protected]>> 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é >> >> [email protected] <mailto:[email protected]> >> >> http://blog.nanthrax.net >> >> Talend - http://www.talend.com >> >> >> >> >> > >> > -- >> > Jean-Baptiste Onofré >> > [email protected] >> > http://blog.nanthrax.net >> > Talend - http://www.talend.com > >
