hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] Increased use of feature branches
Date Tue, 14 Jun 2016 00:22:12 GMT
Thanks for clarifying Andrew. Inline.

On Mon, Jun 13, 2016 at 3:59 PM, Andrew Wang <andrew.wang@cloudera.com>

> On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla <kasha@cloudera.com>
> 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
>> stability changes as Sangjin mentioned?
>> Or, is it okay for trunk-incompat to be based off of an older commit in
>> trunk with (in)frequent rebases? This has the risk of incompatible changes
>> truly rotting. Periodic rebases will ensure these changes don't rot while
>> also easing the burden of hosting two branches; if we choose this route,
>> some guidance of the period and who rebases will be nice.
> Based on my understanding from Vinod on the previous "Looking to..."
> thread, it would be the latter. The goal of trunk-incompat was to avoid
> adding yet-another-branch we need to commit to every time, compared to the
> branch-3 proposal.
> 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 commits, since
> you'd potentially be doing it for multiple large features. If some brave
> and experienced committer is willing to own maintenance of the
> trunk-incompat branch, I think it could work. However, this is a big shift
> from how we've historically done development.

If an incompatible feature is ready (like EC here), should we consider
working towards the next major release? In other words, is it okay to defer
cutting branch-3 until we have a large incompatible feature that would be a
pain to keep up with?

> This is why I leaned toward Chris D's proposal, which is that we cut
> branch-3 for 3.0.0-beta1, at which point trunk moves on to 4.0. In my mind,
> this is the "default" proposal, since it's how we've previously done
> things, with the slight adjustment that we defer cutting branch-3 until we
> start enforcing compatibility. This is my current plan for the Hadoop 3
> series, and we already had a lot of +1's about releasing from trunk on the
> previous thread.

I guess this makes sense.

> If there's a strong advocate for trunk-incompat over branch-3, let's have
> that discussion. However, given that beta is still months (and multiple
> releases) away, I don't think this decision affects my near-term goal of
> getting 3.0.0-alpha1 released.
> Thanks,
> Andrew

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