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