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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>
