In the spirit of some recent conversations about tracking proposals like this, are there JIRAs you can [file and then] mention on this thread?
On Tue, Oct 25, 2016 at 2:07 PM Kenneth Knowles <[email protected]> wrote: > Yea +1. Definitely a real prerequisite to a true runner-independent graph. > > On Tue, Oct 25, 2016 at 1:24 PM Amit Sela <[email protected]> wrote: > > +1 > > On Tue, Oct 25, 2016 at 8:43 PM Robert Bradshaw > <[email protected]> > wrote: > > > +1 > > > > On Tue, Oct 25, 2016 at 7:26 AM, Thomas Weise <[email protected]> wrote: > > > +1 > > > > > > > > > On Tue, Oct 25, 2016 at 3:03 AM, Jean-Baptiste Onofré <[email protected] > > > > > wrote: > > > > > >> +1 > > >> > > >> Agree > > >> > > >> Regards > > >> JB > > >> > > >> > > >> > > >> On Oct 25, 2016, 12:01, at 12:01, Aljoscha Krettek < > [email protected] > > > > > >> wrote: > > >> >+1 This sounds quite straightforward. > > >> > > > >> >On Tue, 25 Oct 2016 at 01:36 Thomas Groh <[email protected]> > > >> >wrote: > > >> > > > >> >> Hey everyone, > > >> >> > > >> >> I've been working on a declaration of intent for how we want to use > > >> >> PipelineOptions and an API change to be consistent with that > intent. > > >> >This > > >> >> is generally part of the move to the Runner API, specifically the > > >> >desire to > > >> >> be able to reuse Pipelines and the ability to choose runner at the > > >> >time of > > >> >> the call to run. > > >> >> > > >> >> The high-level summary is I wan to remove the > > >> >Pipeline.getPipelineOptions > > >> >> method. > > >> >> > > >> >> I believe this will be compatible with other in-flight proposals, > > >> >> especially Dynamic PipelineOptions, but would love to see what > > >> >everyone > > >> >> else thinks. The document is available at the link below. > > >> >> > > >> >> > > >> >> > > >> >https://docs.google.com/document/d/1Wr05cYdqnCfrLLqSk- > > >> -XmGMGgDwwNwWZaFbxLKvPqEQ/edit?usp=sharing > > >> >> > > >> >> Thanks, > > >> >> > > >> >> Thomas > > >> >> > > >> > > > >
