[DISCUSS] Working in master or feature branch for WAL refactoring?

[Josh Elser <el...@apache.org>]

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

Re: [DISCUSS] Working in master or feature branch for WAL refactoring?

[Josh Elser <el...@apache.org>]

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 <bu...@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 <el...@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
>>>
>>
> 

Re: [DISCUSS] Working in master or feature branch for WAL refactoring?

["张铎 (Duo Zhang)" <pa...@gmail.com>]

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 <bu...@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 <el...@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
> >
>

Re: [DISCUSS] Working in master or feature branch for WAL refactoring?

[Sean Busbey <bu...@apache.org>]

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 <el...@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
>