+1 to a Gradle fixit day/week. I agree with Romain that we should make an
effort quit this dual state. The Go, Go PreCommit and various container
image Gradle builds, I think, are in a reasonable state (modulo some
documentation updates).

On Wed, Mar 7, 2018 at 1:29 PM, Kenneth Knowles <k...@google.com> wrote:

> SGTM. I should also say that every day is Gradle fixit day for me, as I
> have been using only Gradle (with IntelliJ) for a while :-). If anyone is
> hesitant, definitely it is ready to be used for normal dev.
>
> Seems like changing the messaging in onboarding docs is the main thing to
> fixit.
>
> Based on https://builds.apache.org/view/A-D/view/Beam/ and our failure
> spam level the performance tests are mostly not healthy anyhow. So is there
> any high level blocker to switching them or is it just someone sitting down
> with each one?
>
> Kenn
>
>
> On Wed, Mar 7, 2018 at 1:22 PM Lukasz Cwik <lc...@google.com> wrote:
>
>> Largest outstanding areas are:
>> * Documentation relevant to the contributors guide/release process/testing
>> * Performance tests
>>
>> There has been good progress towards:
>> * Release artifact validations and generation
>> * ValidatesRunner post commits
>> * Pre commits
>> * Container builds
>>
>>
>> On Wed, Mar 7, 2018 at 1:19 PM, Reuven Lax <re...@google.com> wrote:
>>
>>> I think Alan was making progress on the Gradle build.
>>>
>>> What do people think of a "fixit" day for Gradle work? (or given that
>>> people are distributed, maybe a fixit week, where everyone takes one day
>>> from the week).
>>>
>>>
>>> On Wed, Mar 7, 2018 at 1:17 PM Kenneth Knowles <k...@google.com> wrote:
>>>
>>>> I also cannot drop everything to work on Gradle build, but maybe it
>>>> isn't that drastic anyhow. Now that we have ValidatesRunner and NeedsRunner
>>>> tests and some progress on the release, is there any other known missing
>>>> functionality in the Gradle builds? Archetypes? Docker container images?
>>>>
>>>>
>>>> On Wed, Mar 7, 2018 at 1:12 PM Lukasz Cwik <lc...@google.com> wrote:
>>>>
>>>>> I am working on various projects and may not be able to pause my work
>>>>> for a couple of weeks while the build/test process is migrated.
>>>>>
>>>>> What is everyone thinking about Romain's suggestion because If I'm the
>>>>> only person in such a situation, I would be willing to go along with the
>>>>> plan.
>>>>>
>>>>> On Wed, Mar 7, 2018 at 12:59 PM, Romain Manni-Bucau <
>>>>> rmannibu...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Le 7 mars 2018 20:21, "Lukasz Cwik" <lc...@google.com> a écrit :
>>>>>>
>>>>>> Note that Alan Myrvold has been making steady progress making the
>>>>>> release process via Gradle a reality:
>>>>>> 1) Creating a jenkins job which can run the quickstart validation
>>>>>> against nightly snapshots and also can be used for release candidates (
>>>>>> https://github.com/apache/beam/pull/4252)
>>>>>> 2) Building a release candidate using Gradle (
>>>>>> https://github.com/apache/beam/pull/4812)
>>>>>>
>>>>>> Also, Gradle is the tool that has been selected already and there was
>>>>>> a community discussion about what was needed for the migration to occur
>>>>>> with a clear set of criteria. Romain, it doesn't seem like we should 
>>>>>> ignore
>>>>>> that criteria or are you suggesting we change that criteria (if yes, 
>>>>>> how)?
>>>>>>
>>>>>>
>>>>>> No, no. My goal is just to quit this state.
>>>>>>
>>>>>> Let s draft a plan:
>>>>>>
>>>>>> 1. 2.4 is released - i assume it is done with mvn here
>>>>>> 2. We drop all poms and jenkins mvn config
>>>>>> 3. We fix all build issues if so (let say in a week)
>>>>>> 4. Pr can nees updates but no more mvn merge
>>>>>>
>>>>>> April is gradle month :)
>>>>>>
>>>>>> Wdyt?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 7, 2018 at 10:39 AM, Romain Manni-Bucau <
>>>>>> rmannibu...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 7 mars 2018 17:34, "Lukasz Cwik" <lc...@google.com> a écrit :
>>>>>>>
>>>>>>> Thanks for bringing this up Romain but I believe your data points on
>>>>>>> pass rates are only partially correct.
>>>>>>>
>>>>>>>
>>>>>>> Sure sure, it is mainly about my own PR which a very small % of the
>>>>>>> whole project ;).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In the past week the Java Gradle precommit passed 46.34% of the time
>>>>>>> compared to the Java Maven precommit which passed 46.15% of the time. 
>>>>>>> When
>>>>>>> I looked at these numbers in mid January they were around 37% so there 
>>>>>>> has
>>>>>>> been some improvement. Regardless of the build tool it seems that our 
>>>>>>> pass
>>>>>>> rates aren't stellar for the Java build and are causing the community to
>>>>>>> not follow best practices (wait for precommits to be green before 
>>>>>>> merging).
>>>>>>> I know that on the website we used the mergebot to ensure that things
>>>>>>> passed before they were merged, should we institute this on the master
>>>>>>> branch or are their any other ideas?
>>>>>>>
>>>>>>> As a side note we had achieved the goals we set out to not need to
>>>>>>> maintain the Maven precommit and have authored the first PR to drop the
>>>>>>> Maven precommit:  https://github.com/apache/beam/pull/4814
>>>>>>>
>>>>>>>
>>>>>>> Well, I'd be for a strong switch otherwise PR will keep using maven,
>>>>>>> jenkins will not test the code and at the end we fail to deliver 
>>>>>>> something
>>>>>>> consistent. So whatever tool is selected I'm tempted to say drop other
>>>>>>> build files and jenkins hooks references.
>>>>>>>
>>>>>>> What about doing it after 2.4 vote?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 7, 2018 at 2:24 AM, Romain Manni-Bucau <
>>>>>>> rmannibu...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Up,
>>>>>>>>
>>>>>>>> We discussed to have a strong switch to gradle or rollback to maven
>>>>>>>> around april to not be blocked by the build tool. I noticed gradle 
>>>>>>>> build
>>>>>>>> rarely passes on PR and kind of blurry our vision - not sure why 
>>>>>>>> exactly.
>>>>>>>> Also, PR don't always contain the gradle updates - generally
>>>>>>>> dependencies+plugins are added in pom.xml AFAIK, so it seems the 
>>>>>>>> adoption
>>>>>>>> is very slow to not say rejected.
>>>>>>>>
>>>>>>>> What do we do about that? When do we drop the double build
>>>>>>>> maintenance - whatever is picked?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>>>>>>
>>>>>>>> 2018-01-12 6:30 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com
>>>>>>>> >:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 11 janv. 2018 23:13, "Kenneth Knowles" <k...@google.com> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>> On Thu, Jan 11, 2018 at 8:43 AM, Romain Manni-Bucau <
>>>>>>>>> rmannibu...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> 2. gradle build doesn't use the same output directory than maven
>>>>>>>>>> so it is not really smooth to have both and have to maintain both
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I also have an opinion on this. It is useful and reasonable to be
>>>>>>>>> able to build even when the source is on a read-only filesystem. 
>>>>>>>>> Maven's
>>>>>>>>> defaults are undesirable and require workarounds. We shouldn't mimic 
>>>>>>>>> the
>>>>>>>>> behavior, but actually should set gradle up to build to a directory 
>>>>>>>>> outside
>>>>>>>>> the source tree always, if we can.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hmm, which is something you can do with maven as well so not sure
>>>>>>>>> I get it.
>>>>>>>>>
>>>>>>>>> Also note the thread is no more about the technical points but
>>>>>>>>> more the sources maintenance and consistency.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Kenn
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>

Reply via email to