I'd love to see us more aggressively updating the stable pointer.
I spent a but of time at the last hbasecon west socializing more EOL, but
as Mikhail mentions we can't make 1.3 the stable line while we know it's
broken. AFAIK, that same problem is in brach-1.4.
We could immediately EOL 1.3 and then declare 1.4.1 stable once the problem
is fixed. (Aiming the fix to 1.4.1 so that Andrew doesn't need to stop
before making a 1.4.0 if his other stabilization efforts finish first.)
This gets us fewer branches now and a plan to move the stable pointer.
On Aug 8, 2017 05:17, "Mikhail Antonov" <olorinb...@gmail.com> wrote:
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,
> branch-1.1 active currently. If a dirty bug fix, the applier is
> 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
> 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?