Re: [DISCUSS] Increased use of feature branches

2016-06-15 Thread Steve Loughran
> On 13 Jun 2016, at 22:49, Colin McCabe wrote: > > Feature branch code will receive fewer test runs > since it's not tested in every precommit build like trunk code is. I do > agree that good and well-thought out tests should be a precondition of > merging any big feature

Re: [DISCUSS] Increased use of feature branches

2016-06-14 Thread Andrew Wang
> > I agree with the concerns you raise around feature rot. For a feature like >> EC, it'd be untenable to leave it in trunk-incompat since the rebases would >> be impossible. I imagine we'd also need a very motivated maintainer (or >> maintainers) to handle the periodic integration of new trunk

Re: [DISCUSS] Increased use of feature branches

2016-06-13 Thread Andrew Wang
On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla wrote: > I would like to understand the trunk-incompat part of the proposal a > little better. > > Is trunk-incompat always going to be a superset of trunk? If yes, is it > just a change in naming convention with a hope that

Re: [DISCUSS] Increased use of feature branches

2016-06-13 Thread Colin McCabe
On Mon, Jun 13, 2016, at 12:41, Anu Engineer wrote: > Hi Colin, > > >Even if everyone used branches for all development, person X might merge > >their branch before person Y, forcing person Y to do a rebase or merge. > >It is not the presence of absence of branches that causes the need to >

Re: [DISCUSS] Increased use of feature branches

2016-06-13 Thread Gangumalla, Uma
On 6/13/16, 12:41 PM, "Anu Engineer" wrote: >Hi Colin, > >>Even if everyone used branches for all development, person X might merge >>their branch before person Y, forcing person Y to do a rebase or merge. >>It is not the presence of absence of branches that causes

Re: [DISCUSS] Increased use of feature branches

2016-06-13 Thread Anu Engineer
Hi Colin, >Even if everyone used branches for all development, person X might merge >their branch before person Y, forcing person Y to do a rebase or merge. >It is not the presence of absence of branches that causes the need to >merge or rebase, but the presence of absence of "churn." You are

Re: [DISCUSS] Increased use of feature branches

2016-06-13 Thread Colin McCabe
On Sun, Jun 12, 2016, at 05:06, Steve Loughran wrote: > > On 10 Jun 2016, at 20:37, Anu Engineer wrote: > > > > I actively work on two branches (Diskbalancer and ozone) and I agree with > > most of what Sangjin said. > > There is an overhead in working with branches,

Re: [DISCUSS] Increased use of feature branches

2016-06-12 Thread Steve Loughran
> On 10 Jun 2016, at 20:37, Anu Engineer wrote: > > I actively work on two branches (Diskbalancer and ozone) and I agree with > most of what Sangjin said. > There is an overhead in working with branches, there are both technical costs > and administrative issues >

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Karthik Kambatla
progress as additional vote process get >>> involved even >>> >> > the feature is simple and harmless. >>> >> > >>> >> Thanks Junping, those are valid concerns. I think we should clearly >>> >> separate incompatible w

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Sangjin Lee
alid concern. I think our rule-of-thumb > >> should be that, small-medium new features should be proposed as a single > >> JIRA/patch (as we recently did for HADOOP-12666). If the complexity goes > >> beyond a single JIRA/patch, use a feature branch. > >> > &g

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Anu Engineer
tly from trunk. >> > >> > - This point doesn't necessarily need to be resolved now though, since >> > again we're still doing alphas. >> > No. I think we have to settle down this first. Without a common agreed >> and >> > transparent release process and

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Sangjin Lee
> beta) bits is only called a private release but not a official apache > > hadoop release (even alpha). > > > > > > Thanks, > > > > Junping > > ____ > > From: Karthik Kambatla <ka...@cloudera.com> > > Sent: Frid

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Zhe Zhang
m> > Sent: Friday, June 10, 2016 7:49 AM > To: Andrew Wang > Cc: common-...@hadoop.apache.org; hdfs-dev@hadoop.apache.org; > mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org > Subject: Re: [DISCUSS] Increased use of feature branches > > Thanks for restarting this

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Karthik Kambatla
ing the approach for 3.x. The new proposal forces following these requirements and hence I like it more. > > Thanks, > > Junping > > From: Karthik Kambatla <ka...@cloudera.com> > Sent: Friday, June 10, 2016 7:49 AM > To: Andrew Wang > Cc: common-...@hado

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Junping Du
m> Sent: Friday, June 10, 2016 7:49 AM To: Andrew Wang Cc: common-...@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org Subject: Re: [DISCUSS] Increased use of feature branches Thanks for restarting this thread Andrew. I really hope

Re: [DISCUSS] Increased use of feature branches

2016-06-10 Thread Karthik Kambatla
Thanks for restarting this thread Andrew. I really hope we can get this across to a VOTE so it is clear. I see a few advantages shipping from trunk: - The lack of need for one additional backport each time. - Feature rot in trunk Instead of creating branch-3, I recommend creating

[DISCUSS] Increased use of feature branches

2016-06-10 Thread Andrew Wang
Hi all, On a separate thread, a question was raised about 3.x branching and use of feature branches going forward. We discussed this previously on the "Looking to a Hadoop 3 release" thread that has spanned the years, with Vinod making this proposal (building on ideas from others who also