Unless objection, I was going to add support for hbck2[1] into branch-2.0 and branch-2.1; i.e. hbck2 support would show up on a point release in 2.1.1 and 2.0.3. hbck2 is made up of a client tool that lives at hbase-hbck2 and a new HbckService hosted by the Master. It is the latter that would be added on point release.
This goes against our general philosophy of bug-fixes only on point-release but the thinking is that we make an exception for a critical 'fixup' tool. Some notes: * Above comes of some discussion done on the tail of https://issues.apache.org/jira/browse/HBASE-19121 * The 2.1.0 and <= 2.0.2 releases have no hbck2 support. The hbck2 tool will exit and ask the user upgrade. * The suggestion that hbck2 only show up in the next minor release -- 2.2.0 -- was shot down because it would leave branch-2.0 and branch-2.1 releases without a fixup tooling. * The HbckService is distinct and should not disturb normal operation. It exposes new API for the hbck2 client tool to pull on. It is not exposed as 'public' and is awkward to get at so should not show up on user's radar other than via the hbck2 client tool (TODO: verify). Shout if you think otherwise. Thanks, S 1. hbck2 is the replacement for the original hbck tool. hbck (A.K.A hbck1) does not work against hbase-2.x clusters.
