hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Chiang <rchi...@cloudera.com>
Subject Re: [DISCUSS] Developing features in branches
Date Thu, 30 Apr 2015 17:34:46 GMT
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 <zshen@hortonworks.com> 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 <subru.vk@gmail.com>
> Sent: Wednesday, April 29, 2015 7:16 PM
> To: yarn-dev@hadoop.apache.org
> 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 <sjlee0@gmail.com> wrote:
>
> > Ah, I missed that part (obviously). Fantastic!
> >
> > On Tue, Apr 28, 2015 at 5:31 PM, Sean Busbey <busbey@cloudera.com>
> wrote:
> >
> > > On Apr 28, 2015 5:59 PM, "Sangjin Lee" <sjlee0@gmail.com> 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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message