I became an advocate of feature branches instead of incremental changes on master after having to deal with the fall out of half-done features that added drag in the codebase but never made it to a state where downstream users could reliably interact with the feature. A specific example that leaps to mind is distributed log replay. That said the work of Zach, et al over on "Read Replica Clusters"[1] has made sympathetic again to the costs of a strict feature branch approach.
Still, having a partially implemented feature in master that would block a release is a bad idea, I think. We're already ~1.25 years since branch-2 came off of master, probably a bit long if we're doing time-based release trains. Though I don't know what would justify a feature-driven release there. Are these things we could put behind a feature-flag? Probably not? [1]: https://issues.apache.org/jira/browse/HBASE-18477 On Tue, Sep 25, 2018 at 8:53 AM Josh Elser <els...@apache.org> wrote: > > Hi, > > Under the umbrella of HBASE-20951, we had initial said that we'd start > landing code changes on a feature branch when we get there. Sergey S > asked the good question to me the other day: "why a feature branch and > not master?" > > Honestly, I don't have a good answer. The goal in implementation is to > move incrementally and not leave things "broken" when possible. Assuming > that we can do that, using a feature branch would just create pain on > the eventual merge back to master. > > Do folks have strong feelings here? Is using master better to prevent > review "debt" from piling up when the merge-vote comes? Or, do people > foresee an HBase 3 in the works before this work would be done (sometime > in 2019)? > > Would like to hear your input. > > - Josh >
