+1
On Wed, Mar 7, 2018 at 2:21 PM Robert Bradshaw <rober...@google.com> wrote: > +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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>> >> -- ------- Jason Kuster Apache Beam / Google Cloud Dataflow
