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
