+1 to a fixit day. I'd be happy to help out myself.
On Wed, Mar 7, 2018 at 1:49 PM Henning Rohde <hero...@google.com> wrote: > +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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>> >
