beam-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [VOTE] Use Gradle for Apache Beam developmental processes
Date Wed, 29 Nov 2017 15:45:46 GMT
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é <jb@nanthrax.net 
> <mailto:jb@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é
>     jbonofre@apache.org <mailto:jbonofre@apache.org>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
> 
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message