Vrushali, Sure we can wait TSv2 merged before merge resource profile branch.
Andrew, My understanding is you're going to cut branch-3.0 for 3.0-beta1, and the same branch (branch-3.0) will be used for 3.0-GA as well. So my question is, there're several features (TSv2, resource profile, YARN-5734) are targeted to merge to 3.0-GA but not 3.0-beta1, which branch we should commit to, and when we can commit? Also, similar to 3.0.0-alpha1 to 4, you will cut branch-3.0.0-beta1, correct? Thanks, Wangda On Tue, Aug 29, 2017 at 11:05 AM, Andrew Wang <andrew.w...@cloudera.com> wrote: > Sure. Ping me when the TSv2 goes in, and I can take care of branching. > > We're still waiting on the native services and S3Guard merges, but I don't > want to hold branching to the last minute. > > On Tue, Aug 29, 2017 at 10:51 AM, Vrushali C <vrushalic2...@gmail.com> > wrote: > >> Hi Andrew, >> As Rohith mentioned, if you are good with it, from the TSv2 side, we are >> ready to go for merge tonight itself (Pacific time) right after the voting >> period ends. Varun Saxena has been diligently rebasing up until now so most >> likely our merge should be reasonably straightforward. >> >> @Wangda: your resource profile vote ends tomorrow, could we please >> coordinate our merges? >> >> thanks >> Vrushali >> >> >> On Mon, Aug 28, 2017 at 10:45 PM, Rohith Sharma K S < >> rohithsharm...@apache.org> wrote: >> >>> On 29 August 2017 at 06:24, Andrew Wang <andrew.w...@cloudera.com> >>> wrote: >>> >>> > So far I've seen no -1's to the branching proposal, so I plan to >>> execute >>> > this tomorrow unless there's further feedback. >>> > >>> For on going branch merge threads i.e TSv2, voting will be closing >>> tomorrow. Does it end up in merging into trunk(3.1.0-SNAPSHOT) and >>> branch-3.0(3.0.0-beta1-SNAPSHOT) ? If so, would you be able to wait for >>> couple of more days before creating branch-3.0 so that TSv2 branch merge >>> would be done directly to trunk? >>> >>> >>> >>> > >>> > Regarding the above discussion, I think Jason and I have essentially >>> the >>> > same opinion. >>> > >>> > I hope that keeping trunk a release branch means a higher bar for >>> merges >>> > and code review in general. In the past, I've seen some patches >>> committed >>> > to trunk-only as a way of passing responsibility to a future user or >>> > reviewer. That doesn't help anyone; patches should be committed with >>> the >>> > intent of running them in production. >>> > >>> > I'd also like to repeat the above thanks to the many, many contributors >>> > who've helped with release improvements. Allen's work on >>> create-release and >>> > automated changes and release notes were essential, as was Xiao's work >>> on >>> > LICENSE and NOTICE files. I'm also looking forward to Marton's site >>> > improvements, which addresses one of the remaining sore spots in the >>> > release process. >>> > >>> > Things have gotten smoother with each alpha we've done over the last >>> year, >>> > and it's a testament to everyone's work that we have a good >>> probability of >>> > shipping beta and GA later this year. >>> > >>> > Cheers, >>> > Andrew >>> > >>> > >>> >> >> >
