+1 (binding). On Thu, 30 Nov 2017 at 2:06 AM, Eugene Kirpichov <[email protected]> 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 <[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 >> >> 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 >>> >> >>
