I agree with Romain.
Further more, after have worked on the Gradle build last week, I saw some
difference between the actions performed by the Maven and Gradle builds.
For instance, Nextmark build is not equivalent between Maven and Gradle.
I think we should align both or at least agree about actions that should be
done.
Gradle build looks good to me but, IMHO, it's still require some alignments and
polishing.
Regards
JB
On 12/16/2017 08:59 AM, Romain Manni-Bucau wrote:
@Lukasz: there was a vote on gradle and I think it won with the condition there
is a dryrun release to validate the external visibility of the project. If this
thread passes you will hit the same blocker normally. My point was not "dont
move" but "if you want to move, please make it fast or dont make it". There are
work to do on the build - protobuf, shades topics - and both will likely not be
maintained :(. So concretely do a "fake" release on nexus/dist-dev (you drop it
once it has bezn shared in the vote thread and validated), PR how to do it on
the website (release guide) and close the vote, no?
Le 16 déc. 2017 00:26, "Reuven Lax" <re...@google.com <mailto:re...@google.com>>
a écrit :
+1 to insisting on equivalent test coverage
On Dec 15, 2017 4:23 PM, "Lukasz Cwik" <lc...@google.com
<mailto:lc...@google.com>> wrote:
Might as well as make it explicit and add:
* the test coverage is the same or better
On Fri, Dec 15, 2017 at 1:54 PM, Robert Bradshaw <rober...@google.com
<mailto:rober...@google.com>> wrote:
+1 to these being minimal criteria. (I assume there's an implicit
"the
coverage is the same or better" as well?)
On Fri, Dec 15, 2017 at 12:37 PM, Lukasz Cwik <lc...@google.com
<mailto:lc...@google.com>> wrote:
> Romain, choosing the criteria is about setting the minimum
expectations and
> your welcome to suggest alternative criteria.
> Even though the criteria is the minimum expectations we can see
that the
> Gradle build has averaged 130 mins while the maven build has
averaged 201
> mins for the Java pre-commit.
>
> On Fri, Dec 15, 2017 at 12:13 PM, Romain Manni-Bucau
<rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>
> wrote:
>>
>> If it is the ~same Im not sure i see the point to move but
please dont
>> keep gradle and mvn in master - more than jenkins ;). It makes
it hard to
>> follow the project and do prs.
>>
>> Le 15 déc. 2017 20:42, "Lukasz Cwik" <lc...@google.com
<mailto:lc...@google.com>> a écrit :
>>>
>>> I'm proposing that the criteria to remove a
PreCommit/PostCommit running
>>> in Jenkins via Maven is that and any Maven based configuration
supporting
>>> the execution:
>>> * The pass rate of the Jenkins job via Gradle is the same or
better then
>>> Maven over the past 7 days.
>>> * The average execution time via Gradle is the same or better
then Maven
>>> over the past 7 days.
>>>
>>> I pulled down some initial stats for the relevant Jenkins jobs:
>>> Test name,# Builds,Pass Rate (%),Build time (mins)
>>> beam_PerformanceTests_Python,27,70.37,28.2
>>> beam_PerformanceTests_Spark,27,0.00,0.7
>>> beam_PostCommit_Java_JDK_Versions_Test,27,0.00,1.8
>>> beam_PostCommit_Java_MavenInstall,42,64.29,142.6
>>> beam_PostCommit_Java_MavenInstall_Windows,26,0.00,61.3
>>> beam_PostCommit_Java_ValidatesRunner_Apex,43,79.07,62.6
>>> beam_PostCommit_Java_ValidatesRunner_Dataflow,40,57.50,118.0
>>> beam_PostCommit_Java_ValidatesRunner_Flink,42,95.24,15.5
>>> beam_PostCommit_Java_ValidatesRunner_Spark,42,80.95,60.5
>>> beam_PostCommit_Python_ValidatesRunner_Dataflow,42,80.95,23.3
>>> beam_PostCommit_Python_Verify,42,73.81,72.2
>>> beam_PreCommit_Go_MavenInstall,140,96.43,5.1
>>> beam_PreCommit_Java_GradleBuild,139,36.69,129.6
>>> beam_PreCommit_Java_MavenInstall,136,39.71,201.2
>>> beam_PreCommit_Python_MavenInstall,140,51.43,123.8
>
>
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
