Re: [DISCUSS] Increased use of feature branches

> > 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

Thanks for clarifying Andrew. Inline. On Mon, Jun 13, 2016 at 3:59 PM, Andrew Wang wrote: > > 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. >>

Re: [DISCUSS] Increased use of feature branches

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

> 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

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

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

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

> 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

a.com> > Sent: Friday, June 10, 2016 7:49 AM > To: Andrew Wang > Cc: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; > mapreduce-dev@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

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

m> Sent: Friday, June 10, 2016 7:49 AM To: Andrew Wang Cc: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; mapreduce-dev@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

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