We could try LimitedPrivate(HBCK) and see how it goes.
On Thu, Jul 26, 2018 at 2:46 AM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > 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 > > > > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
