Outstanding pull requests were created against master branch, so if/when they merge, the committers would presumably merge them to master branch. If the committer/author agree that the intended target is really the stable/1.2 branch, I suppose the committer could push it there just as easily.
--Steve -----Original Message----- From: Dave Birdsall [mailto:[email protected]] Sent: Wednesday, October 7, 2015 12:07 PM To: [email protected] Subject: RE: Start another branch for HBase 1.0 support What would be the impact on outstanding pull requests? -----Original Message----- From: Hans Zeller [mailto:[email protected]] Sent: Wednesday, October 7, 2015 12:01 PM To: dev <[email protected]> Subject: Re: Start another branch for HBase 1.0 support Hi, My two cents: If developers need to submit their changes into two branches, then I would vote to hold of another couple of weeks, as Roberta mentions. If we can do a wholesale merge of 1.2.0 into the new hbase1.0 distro, then splitting now would be fine. Thanks, Hans On Wed, Oct 7, 2015 at 10:40 AM, Roberta Marton <[email protected]> wrote: > Realistically, it will take another couple of weeks to put all the > pieces together and release our first tarball to the test site for release > 1.2.0. > After we get the source released, it may be a couple of more weeks to > get it through the Apache process. > But, if everything thing goes like clockwork, it could be less time. > > Roberta > > -----Original Message----- > From: Dave Birdsall [mailto:[email protected]] > Sent: Wednesday, October 7, 2015 10:23 AM > To: [email protected] > Subject: RE: Start another branch for HBase 1.0 support > > What is the proposed timing? > > -----Original Message----- > From: Steve Varnau [mailto:[email protected]] > Sent: Wednesday, October 7, 2015 10:15 AM > To: [email protected] > Subject: Start another branch for HBase 1.0 support > > Trafodion Developers, > > > > We are working toward our first release (1.2) under Incubator project. > Meanwhile, folks are starting work on supporting HBase 1.x for future > release. So I’d like to propose we start another branch to support > both lines of work. > > > > If we do that, it does imply some extra overhead for changes that > apply to both lines of work. Each developer will have to submit change > to each branch, or someone will need to occasionally merge all the 1.2 > work forward. > Given that each developer would know their change-set the best they > should be the ones to submit it to each branch. > > > > **Given that overhead, do you agree that it is time to start another > branch?** > > > > Strategy we’ve used in past is to put the imminent release on a side > branch (e.g., stable/1.2) that can be used to stabilize code for > release and for any post-release patches. Which would allow new > feature development to continue on master branch. > > > > If majority of changes are still going to be aimed for 1.2 release for > some time to come, we could keep 1.2 on master branch and have a > temporary feature branch for hbase1.0, but my proposal is to go ahead > to create > stable/1.2 and allow next release work to come into master branch. > > > > **Do you agree to create stable/1.2, and open master branch for net > release > features?** > > > > Let me know what you think. I’ll work on setting up build & test > automation to support two branches. > > > > --Steve >
