OK. I don't have a strong feeling about preserving the Java ULR on `master`. I think since deleting such a large chunk of code is a big deal, this is a good thing for an explicit vote. That way, anyone who is following dev@ and wants to preserve the Java ULR on `master` can issue their -1 vote and we can respect it (but ask to get the testing green). I would suggest opening a PR with the change, opening a "lazy consensus" vote on dev@ and then waiting a decent amount of time before merging the deletion PR.
Kenn On Fri, Mar 15, 2019 at 4:43 PM Daniel Oliveira <[email protected]> wrote: > The ULR used a bunch of code forked from the DirectRunner but I don't > think it currently shares anything. And if it does share any code that I > don't know about I expect that the dependency is one-way, i.e. removing the > ULR shouldn't affect the DirectRunner. The only shared code I know of is > between the ULR and other portable runners, particularly Flink, but I don't > think that would be difficult to isolate. > > I'm in support of disabling the ULR tests and ok with removing the ULR as > long as we make sure it can be revived if we want, like with Mikhail's > suggestion of tagging the commit. I can help with the removal of the ULR > code since I know specifics about the codebase. > > On Thu, Mar 14, 2019 at 2:25 PM Kenneth Knowles <[email protected]> wrote: > >> I know the Java DirectRunner shares a lot of code with the ULR. I'm a bit >> unclear on the delta and how independent they are. >> >> Kenn >> >> On Thu, Mar 14, 2019 at 2:10 PM Mikhail Gryzykhin <[email protected]> >> wrote: >> >>> @Kenneth >>> If we disable tests, I'd call Java ULR a dead code. >>> >>> One of the better compromises: >>> 1. disable tests. >>> 2. Add tag to the last commit where Java ULR existed. >>> 3. Remove Java ULR from head. >>> >>> Keeping history, no extra dead code at head. >>> >>> --Mikhail >>> >>> Have feedback <http://go/migryz-feedback>? >>> >>> >>> On Thu, Mar 14, 2019 at 1:02 PM Ankur Goenka <[email protected]> wrote: >>> >>>> On that note, we should also think about adding PVR for python >>>> reference runners. Jira: >>>> https://issues.apache.org/jira/browse/BEAM-6837 >>>> >>>> >>>> On Thu, Mar 14, 2019 at 12:57 PM Kenneth Knowles <[email protected]> >>>> wrote: >>>> >>>>> How about this compromise: >>>>> >>>>> 1. disable the test since clearly no one is relying on the >>>>> functionality that is broken >>>>> 2. leave the Java ULR as-is for now, and a volunteer can pick it up >>>>> and make it work if they want >>>>> >>>>> Kenn >>>>> >>>>> On Thu, Mar 14, 2019 at 11:41 AM Mikhail Gryzykhin <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> We have Python PVR Reference post-commit tests failing for quite some >>>>>> time now. These are tests for java reference runner. >>>>>> >>>>>> According to this thread >>>>>> <https://lists.apache.org/thread.html/b235f8ee55a737ea399756edd80b1218ed34d3439f7b0ed59bfa8e40@%3Cdev.beam.apache.org%3E>, >>>>>> we are deciding what to do with java reference runner and might want to >>>>>> remove it from code base. >>>>>> >>>>>> My question is: do we want to a) invest time in fixing python PVR >>>>>> tests, or b) disable this test and start cleaning up code? >>>>>> >>>>>> a) Is worth it if we want to invest into java reference runner in the >>>>>> future. >>>>>> b) Is worth if we want to invest into Python and forfeit java >>>>>> reference runner. >>>>>> >>>>>> Option b) seem more reasonable to me atm, since most people lean >>>>>> towards going forward with Python reference runner. >>>>>> >>>>>> Please, share your thoughts. >>>>>> >>>>>> Regards, >>>>>> --Mikhail >>>>>> >>>>>> Have feedback <http://go/migryz-feedback>? >>>>>> >>>>>
