+1 on having release trains scheduled. Romain: Do you have a list of PRs that could benefit from increased focus if they want to make it on the upcoming train?
On Tue, Feb 20, 2018 at 3:30 PM Ahmet Altay <[email protected]> wrote: > +1 for having regular release cycles. Finalizing a release takes time in > the order of a few weeks and starting a new release soon after the previous > one is a reliable way for having releases every 6 weeks. > > 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 >> > >
smime.p7s
Description: S/MIME Cryptographic Signature
