Ok In terms of what I'd like included, here is the list:
1. https://github.com/apache/beam/pull/4412 (important to prevent regressions) 2. https://github.com/apache/beam/pull/4674 (can need some more work but can break some api if we do, so current state is a functional trade off). On a more personal side Im blocked by this one for some features. 3. https://github.com/apache/beam/pull/4372 (important cause doesnt make the execution deterministic depending your surefire config, IDE, main usage) Le 21 févr. 2018 01:29, "Reuven Lax" <[email protected]> a écrit : > +1, this is keeping with an every-six weeks cadence. > > Romain, you can always target Jiras to this release, and then the release > manager can decide on a case-by-case basis whether to make sure the fix is > included. > > On Tue, Feb 20, 2018 at 2:30 PM, Robert Bradshaw <[email protected]> > wrote: > >> Yep. I am starting the "Let's do a 2.4.0 release" thread almost >> exactly 6 weeks after JB first started the 2.3.0 release thread. >> >> On Tue, Feb 20, 2018 at 2:20 PM, Charles Chen <[email protected]> wrote: >> > I would like to +1 the faster release cycle process JB and Robert have >> been >> > advocating and implementing, and thank JB for releasing 2.3.0 smoothly. >> > When we block for specific features and increase the time between >> releases, >> > we increase the urgency for PR authors to push for their change to go >> into >> > an upcoming release, which is a feedback loop that results in our >> releases >> > taking months instead of weeks. We should however try to get pending >> PRs >> > wrapped up. >> > >> > On Tue, Feb 20, 2018 at 2:15 PM Romain Manni-Bucau < >> [email protected]> >> > wrote: >> >> >> >> Kind of agree but rythm was supposed to be 6 weeks IIRC, 2.3 is just >> out >> >> so 1 week is a bit fast IMHO. >> >> >> >> Le 20 févr. 2018 23:13, "Robert Bradshaw" <[email protected]> a >> écrit : >> >>> >> >>> One of the main shifts that I think helped this release was explicitly >> >>> not being feature driven, rather releasing what's already in the >> >>> branch. That doesn't mean it's not a good call to action to try and >> >>> get long-pending PRs or similar wrapped up. >> >>> >> >>> On Tue, Feb 20, 2018 at 2:10 PM, Romain Manni-Bucau >> >>> <[email protected]> wrote: >> >>> > There are a lot of long pending PR, would be good to merge them >> before >> >>> > 2.4. >> >>> > Some are bringing tests for the 2.3 release which can be critical to >> >>> > include. >> >>> > >> >>> > Maybe we should list the pr and jira we want it before picking a >> date? >> >>> > >> >>> > Le 20 févr. 2018 22:02, "Konstantinos Katsiapis" < >> [email protected]> >> >>> > a >> >>> > écrit : >> >>> >> >> >>> >> +1 since tf.transform 0.6 depends on Beam 2.4 and Tensorflow 1.6 >> (and >> >>> >> the >> >>> >> latter already has an RC out, so we will likely be blocked on >> Beam). >> >>> >> >> >>> >> On Tue, Feb 20, 2018 at 12:50 PM, Robert Bradshaw >> >>> >> <[email protected]> >> >>> >> wrote: >> >>> >>> >> >>> >>> Now that Beam 2.3.0 went out (and in record time, kudos to all >> that >> >>> >>> made this happen!) It'd be great to keep the ball rolling for a >> >>> >>> similarly well-executed 2.4. A lot has gone in [1] since we made >> the >> >>> >>> 2.3 cut, and to keep our cadence up I would propose a time-based >> cut >> >>> >>> date early next week (say the 28th). >> >>> >>> >> >>> >>> I'll volunteer to do this release. >> >>> >>> >> >>> >>> [1] https://github.com/apache/beam/compare/release-2.3.0...master >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> Gus Katsiapis | Software Engineer | [email protected] | >> >>> >> 650-918-7487 >> > >
