Thanks for clarifying Andrew. Inline. On Mon, Jun 13, 2016 at 3:59 PM, Andrew Wang <andrew.w...@cloudera.com> wrote:
> > 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. > 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 >
