Andrew, First up thanks for tirelessly pushing on 3.0 release.
I am confused about your comment on creating 2 branches as my understanding of Jason's (and Vinod's) comments are that we defer creating branch-3? IMHO, we should consider creating branch-3 (necessary but not sufficient) only when we have: 1. a significant incompatible change. 2. a new feature that cannot be turned off without affecting core components. In summary, I feel we should follow a lazy rather than eager approach towards creating mainline branches. Thanks, Subru On Tue, Aug 29, 2017 at 11:45 AM, Wangda Tan <wheele...@gmail.com> wrote: > Gotcha, make sense, so I will hold commit until you cut the two branches > and TSv2 get committed. > > Thanks, > Wangda > > On Tue, Aug 29, 2017 at 11:25 AM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > > Hi Wangda, > > > > I'll cut two branches: branch-3.0 (3.0.0-SNAPSHOT) and branch-3.0.0-beta1 > > (3.0.0-beta1-SNAPSHOT). This way we can merge GA features to branch-3.0 > but > > not branch-3.0.0-beta1. > > > > Best, > > Andrew > > > > On Tue, Aug 29, 2017 at 11:18 AM, Wangda Tan <wheele...@gmail.com> > wrote: > > > >> 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 > >>>>> > > >>>>> > > >>>>> > >>>> > >>>> > >>> > >> > > >
