Re: [VOTE] Use Gradle for Apache Beam developmental processes

[Lukasz Cwik <lc...@google.com>]

Vote concluded with:
16: +1 (4 binding)
1: -0 (1 binding)
1: -1 (0 binding)

Committers/PMC, please ensure that changes to Maven pom's are
correspondingly seen in Gradle build files as well.

Next steps are to flesh out the details on migration in
https://issues.apache.org/jira/browse/BEAM-3249.

On Wed, Nov 29, 2017 at 6:19 PM, Pei HE <pe...@apache.org> wrote:

> +1
>
> On Thu, Nov 30, 2017 at 8:48 AM, tarush grover <ta...@gmail.com>
> wrote:
>
>> +1 (binding).
>>
>> On Thu, 30 Nov 2017 at 2:06 AM, Eugene Kirpichov <ki...@google.com>
>> 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 <lc...@google.com> 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 <ro...@google.com>
>>>> 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é <jb...@nanthrax.net>
>>>>> 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é <
>>>>> jb@nanthrax.net
>>>>> >> <ma...@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/225dddcfc78f39bbb296a0d
>>>>> 2bbef1caf37e17677c7e5573f0b6fe253@%3Cdev.beam.apache.org%3E
>>>>> >>
>>>>> >> <https://lists.apache.org/thread.html/225dddcfc78f39bbb296a0
>>>>> d2bbef1caf37e17677c7e5573f0b6fe253@%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 <ma...@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
>>>>>
>>>>
>>>>
>