I feel the same way with stack. In general, if we want HBCK to fix something, then it must depend on some internal stuffs of HBase, we need to keep HBCK in sync(I agree that this may not be the truth in the past, but we have to do this...)
Anyway, let's try it first. If it does not work then we can move it back... 2018-07-26 13:54 GMT+08:00 Stack <st...@duboce.net>: > On Tue, Jul 24, 2018 at 10:27 AM Andrew Purtell <apurt...@apache.org> > wrote: > > > If we do this can we also move out hbck version 1? It would be really > weird > > in my opinion to have v2 in a separate repo but v1 shipping with the 1.x > > releases. That would be a source of understandable confusion. > > > > > My sense is that hbck1 is not externalizable; we'd not be able to move it > out of core because it does dirty tricks all over the shop. But lets see... > S > > > > > I believe our compatibility guidelines allow us to upgrade interface > > annotations from private to LP or Public and from LP to Public. These are > > not changes that impact source or binary compatibility. They only change > > the promises we make going forward about their stability. I believe we > can > > allow these in new minors, so we could potentially move hbck out in a > > 1.5.0. > > > > > > On Mon, Jul 23, 2018 at 4:46 PM Stack <st...@duboce.net> wrote: > > > > > On Thu, Jul 19, 2018 at 2:09 PM Umesh Agashe > > <uaga...@cloudera.com.invalid > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > I've had the opportunity to talk about HBCK2 with a few of you. One > of > > > the > > > > suggestions is to to have a separate git repository for HBCK2. Lets > > > discuss > > > > about it. > > > > > > > > In the past when bugs were found in hbck, there is no easy way to > > release > > > > patched version of just hbck (without patching HBase). If HBCK2 has a > > > > separate git repo, HBCK2 versions will not be tightly related to > HBase > > > > versions. Fixing and releasing hbck2, may not require patching HBase. > > > > Though tight coupling will be somewhat loosened, HBCK2 will still > > depend > > > on > > > > HBase APIs/ code. Caution will be required going forward regarding > > > > compatibility. > > > > > > > > What you all think? > > > > > > > > > > > I think this the way to go. > > > > > > We'd make a new hbase-hbck2 repo as we did for hbase-thirdparty? > > > > > > We'd use the hbase JIRA for hbase-hbck2 issues? > > > > > > We'd make hbase-hbck2 releases on occasion that the PMC voted on? > > > > > > Sounds great! > > > St.Ack > > > > > > Thanks, > > > > Umesh > > > > > > > > JIRA: https://issues.apache.org/jira/browse/HBASE-19121. > > > > Doc: > > > > > > > > > > > > > https://docs.google.com/document/d/1NxSFu4TKQ6lY- > 9J5qsCcJb9kZOnkfX66KMYsiVxBy0Y/edit?usp=sharing > > > > > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > >
