I think what Zhijie is talking about is a little different. Work happening in parallel across 2 branches have no clue about each other since they don’t get updates via master. If a bunch of these branches is tried to be merged close to a release then there are likely to be a lot of surprises. As an example, lets say support for speculation and node labels were happening in separate branches. It is very likely that >50% of the code would conflict - not just in code but also in semantics.
Bikas -----Original Message----- From: Ray Chiang [mailto:[email protected]] Sent: Thursday, April 30, 2015 10:35 AM To: [email protected] Subject: Re: [DISCUSS] Developing features in branches 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. > > > > > >
