Hi guys I think everyone has a good will and the issue is more coming from the fact that now 2 build systems have to be maintained - and are not symmetrically maintained :(.
Will be fixee soon so no need to discuss it much IMHO. Next time a major change will be done the impacts once merged should maybe more be taken into account than the cost to evaluate them - like gathering data here was probably cheaper than maintainin both systems. Also the fact the opinions were quite split on the way to move and what means incremental (scm, inputs, ...) or what was and where "fast" was important didnt help to get a clear statement of what was the goal of the switch evaluation. Let's be better next time ;) Le 29 nov. 2017 19:57, "Robert Bradshaw" <rober...@google.com> a écrit : > [Starting a new thread to not hijack the voting one...] > > 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 > > I agree with JB in that there may have been a perception that we were > switching to Gradle without sufficient community feedback. I agree > with Reuven (and you) that the actions were completely reasonable and > done with good intent. > > The only thing I would have done differently (in hindsight!) is been > very explicit on the list "we're merging this to gather more data, any > objections?" I, personally, don't think that needed a vote, but this > would have been a chance for those who felt differently to call for a > vote, which would have been respected if anyone felt strongly. > > - Robert > > > > 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 > > > > >
