For WAL, it is the core of HBase so please use a feature branch. And when merging, it is not a big problem if there are -1s, you just need to have 3 more +1s, according to the asf rule? And in my experience, merging things into master branch is not very hard.
Thanks. Sean Busbey <bus...@apache.org> 于2018年9月26日周三 上午6:42写道: > 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 > > >