On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla <ka...@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. 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. Thanks, Andrew
