Thanks, Sean. Like Duo says, I think we can't "hide" this stuff. For the most part, it shouldn't affect how the system works, but that is both a good thing and a bad thing (when we do introduce a bug).

Thanks for weighing in too, Duo! I'm not worried about the logistics of doing the merge vote. I was more curious if people saw "big merge votes" as being systemic problems.

Happy to hear from others, but the consensus seems to be that folks would still encourage a feature branch here which is just fine! Thanks again.

On 9/25/18 10:22 PM, 张铎(Duo Zhang) wrote:
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



Reply via email to