I totally agree we have too many branches to maintain.
I think we should EOL 1.1. 1.2 has been out and stable for a long time,
doesn't have any outstanding major problems preventing upgrade that I'm
aware of, though obviously Sean would know better.
Speaking of 1.3, there's one issue that I feel needs to be addressed before
we move stable pointer to 1.3 and start EOL-ing 1.2
HBASE-18397, TL;DR - major optimization changes in scanners locking schema
in 1.3 broke store file accounting, which could cause failed long scans,
failed splits and failed snapshots. Many people spent lots and lots of time
fixing various aspects of that, but there are still issues not yet fixed.
Any help in that area would be amazing. This specific issue probably
deserves separate discussion.
On Tue, Aug 8, 2017 at 12:14 AM, Stack <st...@duboce.net> wrote:
> (This came up during dev meeting in Shenzhen) We are running too many
> branches and/or when applying patches, we do not do a good job backporting
> to all active branches, especially fixes.
> We have master, branch-2, branch-1, branch-1.4, branch-1.3, branch-1.2, and
> branch-1.1 active currently. If a dirty bug fix, the applier is backporting
> to 7 branches. It takes a while applying to all especially if the backport
> doesn't go in clean. I suppose the RM could monitor all upstream of them
> and then pull wanted patches back (we could do that too) but seems like a
> burden on an RMer.
> We should EOL a few?
> Nick is on branch-1.1 release at the moment. Perhaps this could be the last
> off branch-1.1.
> 1.2 hosts our current stable release though 1.3 is out. How about we cut a
> release off 1.3, call it stable, and then EOL 1.2 after another release or
> What you all think?