>
> 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 co
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.
>>
>> Is trunk-incompat always going to be a super
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 our approach to trunk
> 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
> which discourages developer
process get
>>> involved even
>>> >> > the feature is simple and harmless.
>>> >> >
>>> >> Thanks Junping, those are valid concerns. I think we should clearly
>>> >> separate incompatible with uncompleted / half-done work in this
gt; is a
>> >> much more tricky question (related to trunk-incompat etc.). But per my
>> >> comment above, IMHO, *not committing uncompleted work to trunk* should
>> be a
>> >> much easier principle to agree upon.
>> >>
>> >>
>>
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
sarily 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 branches in community, any release
>> (alpha,
>&g
beta) bits is only called a private release but not a official apache
> > hadoop release (even alpha).
> >
> >
> > Thanks,
> >
> > Junping
> >
> > From: Karthik Kambatla
> > Sent: Friday, June 10, 2016 7:49 AM
>
, June 10, 2016 7:49 AM
> To: Andrew Wang
> Cc: common-dev@hadoop.apache.org; hdfs-...@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 ho
oposal forces following these requirements and hence I like it more.
>
> Thanks,
>
> Junping
>
> From: Karthik Kambatla
> Sent: Friday, June 10, 2016 7:49 AM
> To: Andrew Wang
> Cc: common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.or
riday, June 10, 2016 7:49 AM
To: Andrew Wang
Cc: common-dev@hadoop.apache.org; hdfs-...@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 we can get this
acros
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 branch-3.
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 comment
14 matches
Mail list logo
