Following up on Zhijie's comments, there's nothing to prevent periodically pulling updates from the "main" branch (e.g. branch-2 or trunk) into the feature branch, is there? Or cherry-picking some changes to alleviate conflict management during branch merging?
I've seen other projects use one of the two techniques above. -Ray On Wed, Apr 29, 2015 at 9:43 PM, Zhijie Shen <[email protected]> wrote: > My 2 cents: > > Branch maintenance cost should be fine if we have few features to be > developed in branches. However, if there're too many, each other branch may > be blind to most of latest code change from others, and trunk/branch-2 > becomes stale. That said, with the increasing adopting of branch > development, it's likely to increase the cost of merging each branch back. > > Some features may last more than one releases, such as RM restarting > before and timeline service now. Even if it's developed in a branch, we may > want to merge its milestones such as phase 1, phase 2 back to > trunk/branch-2 to align with some release before it's completely done. > Moreover, my experience is that the longer a feature stays in the branch, > the more conflicts we have to merge. Hence, it may not be a good idea to > hold a feature in the branch too long before merging it back. > > Thanks, > Zhijie > ________________________________________ > From: Subramaniam V K <[email protected]> > Sent: Wednesday, April 29, 2015 7:16 PM > To: [email protected] > Subject: Re: [DISCUSS] Developing features in branches > > Karthik, thanks for starting the thread. > > Here's my $0.02 based on the experience of working on a feature branch > while adding reservations (YARN-1051). > > Overall a +1 for the approach. > > The couple of pain points we faced were: > 1) Merge cost with trunk > 2) Lack of CI in the feature branch > > The migration to git & keeping the feature branch in continuous sync with > trunk mitigated (1) and with Allen's new test-patch.sh addressing (2), > branches for features especially if used for all major features seems like > an excellent choice. > > -Subru > > On Tue, Apr 28, 2015 at 5:47 PM, Sangjin Lee <[email protected]> wrote: > > > Ah, I missed that part (obviously). Fantastic! > > > > On Tue, Apr 28, 2015 at 5:31 PM, Sean Busbey <[email protected]> > wrote: > > > > > On Apr 28, 2015 5:59 PM, "Sangjin Lee" <[email protected]> wrote: > > > > > > > > > > > That said, in a way we're deferring the cost of cleaning things up > > > towards > > > > the end of the branch. For example, we don't get the same treatment > of > > > the > > > > hadoop jenkins in a branch development. It's left up to the group or > > the > > > > individuals to make sure to run test-patch.sh to ensure tech debt > does > > > not > > > > accumulate. > > > > > > As Allen previously mentioned, the QA bot will run test-patch against > > > feature branches so long as you name the patch file correctly. > > > > > >
