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 <rober...@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é <j...@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é <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/225dddcfc78f39bbb296a0d2bbef1c
> af37e17677c7e5573f0b6fe253@%3Cdev.beam.apache.org%3E
> >>
> >> <https://lists.apache.org/thread.html/225dddcfc78f39bbb296a0d2bbef1c
> af37e17677c7e5573f0b6fe253@%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
>

Reply via email to