+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
