> 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
>
> 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
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
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
>
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
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
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,
> 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
>
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
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
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
> 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
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
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
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
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
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
17 matches
Mail list logo