hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: [DISCUSS] Increased use of feature branches
Date Mon, 13 Jun 2016 22:59:05 GMT
On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla <kasha@cloudera.com>

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

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.

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.


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