Re: [ANNOUNCE] New Committer: Balazs Meszaros

[Umesh Agashe]

Congrats Balazs!

On Thu, Oct 11, 2018 at 3:34 PM Andrew Purtell  wrote:

> Congratulations and welcome Balazs.
>
> On Thu, Oct 11, 2018 at 12:49 PM Sean Busbey  wrote:
>
> > On behalf of the HBase PMC, I'm pleased to announce that Balazs
> > Meszaros has accepted our invitation to become an HBase committer.
> >
> > Thanks for all your hard work Balazs; we look forward to more
> > contributions!
> >
> > Please join me in extending congratulations to Balazs!
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [DISCUSS] Separate Git Repository for HBCK2

[Umesh Agashe]

bq. Seems like you're saying it's not a problem now, but
you're not sure if it would become a problem. Regardless of that, it's a
goal to not be version-specific (and thus, we can have generic hbck-v1
and hbck-v2 tools). LMK if I misread, please :)

Thats right.

On Wed, Jul 25, 2018 at 11:11 AM Josh Elser  wrote:

> Thanks, Umesh. Seems like you're saying it's not a problem now, but
> you're not sure if it would become a problem. Regardless of that, it's a
> goal to not be version-specific (and thus, we can have generic hbck-v1
> and hbck-v2 tools). LMK if I misread, please :)
>
> One more thought, it would be nice to name this repository as
> "operator-tools" or similar (instead of hbck). A separate repo on its
> own release cadence is a nice vehicle for random sorts of recovery,
> slice-and-dice, one-off tools. I think HBCK is one example of
> administrator/operator tooling we provide (certainly, the most used),
> but we have the capacity to provide more than just that.
>
> On 7/24/18 5:55 PM, Umesh Agashe wrote:
> > Thanks Stack, Josh and Andrew for your suggestions and concerns.
> >
> > I share Stack's suggestions. This would be similar to hbase-thirdparty.
> The
> > new repo could be hbase-hbck/hbase-hbck2. As this tool will be used by
> > hbase users/ developers, hbase JIRA can be used for hbck issues.
> >
> > bq. How often does HBCK need to re-use methods and constants from code
> > in hbase-common, hbase-server, etc?
> > bq. Is it a goal to firm up API stability around this shared code.
> >
> > bq. If we do this can we also move out hbck version 1?
> >
> > As HBCK2 tool will be freshly written, we can try to achieve this goal. I
> > think its great idea to move hbck1 to new repo as well. Though I think
> its
> > more involved with hbck1 as the existing code already uses what it can
> from
> > hbase-common and hbase-server etc. modules.
> >
> > bq. How often does HBCK make decisions on how to implement a correction
> > based on some known functionality (e.g. a bug) in a specific version(s)
> > of HBase. Concretely, would HBCK need to make corrections to an HBase
> > installation that are specific to a subset of HBase 2.x.y versions that
> > may not be valid for other 2.x.y versions?
> >
> > I see if this happens too often, compatibility metrics will be
> complicated.
> >
> > Thanks,
> > Umesh
> >
> >
> > On Tue, Jul 24, 2018 at 10:27 AM Andrew Purtell 
> 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.
> >>
> >> 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  wrote:
> >>
> >>> On Thu, Jul 19, 2018 at 2:09 PM Umesh Agashe
> >>  >>>>
> >>> 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
> >>
> >
>

Re: [DISCUSS] Separate Git Repository for HBCK2

[Umesh Agashe]

Thanks Josh! separate 'operator-tools' repo for hbase tools is a great
suggestion. We can work towards it starting with hbck2. Each existing tool
needs to be looked in detail regarding how much code it shares with HBase.

On Wed, Jul 25, 2018 at 11:11 AM Josh Elser  wrote:

> Thanks, Umesh. Seems like you're saying it's not a problem now, but
> you're not sure if it would become a problem. Regardless of that, it's a
> goal to not be version-specific (and thus, we can have generic hbck-v1
> and hbck-v2 tools). LMK if I misread, please :)
>
> One more thought, it would be nice to name this repository as
> "operator-tools" or similar (instead of hbck). A separate repo on its
> own release cadence is a nice vehicle for random sorts of recovery,
> slice-and-dice, one-off tools. I think HBCK is one example of
> administrator/operator tooling we provide (certainly, the most used),
> but we have the capacity to provide more than just that.
>
> On 7/24/18 5:55 PM, Umesh Agashe wrote:
> > Thanks Stack, Josh and Andrew for your suggestions and concerns.
> >
> > I share Stack's suggestions. This would be similar to hbase-thirdparty.
> The
> > new repo could be hbase-hbck/hbase-hbck2. As this tool will be used by
> > hbase users/ developers, hbase JIRA can be used for hbck issues.
> >
> > bq. How often does HBCK need to re-use methods and constants from code
> > in hbase-common, hbase-server, etc?
> > bq. Is it a goal to firm up API stability around this shared code.
> >
> > bq. If we do this can we also move out hbck version 1?
> >
> > As HBCK2 tool will be freshly written, we can try to achieve this goal. I
> > think its great idea to move hbck1 to new repo as well. Though I think
> its
> > more involved with hbck1 as the existing code already uses what it can
> from
> > hbase-common and hbase-server etc. modules.
> >
> > bq. How often does HBCK make decisions on how to implement a correction
> > based on some known functionality (e.g. a bug) in a specific version(s)
> > of HBase. Concretely, would HBCK need to make corrections to an HBase
> > installation that are specific to a subset of HBase 2.x.y versions that
> > may not be valid for other 2.x.y versions?
> >
> > I see if this happens too often, compatibility metrics will be
> complicated.
> >
> > Thanks,
> > Umesh
> >
> >
> > On Tue, Jul 24, 2018 at 10:27 AM Andrew Purtell 
> 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.
> >>
> >> 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  wrote:
> >>
> >>> On Thu, Jul 19, 2018 at 2:09 PM Umesh Agashe
> >>  >>>>
> >>> 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
> >>
> >
>

Re: [DISCUSS] Separate Git Repository for HBCK2

[Umesh Agashe]

Thanks Stack, Josh and Andrew for your suggestions and concerns.

I share Stack's suggestions. This would be similar to hbase-thirdparty. The
new repo could be hbase-hbck/hbase-hbck2. As this tool will be used by
hbase users/ developers, hbase JIRA can be used for hbck issues.

bq. How often does HBCK need to re-use methods and constants from code
in hbase-common, hbase-server, etc?
bq. Is it a goal to firm up API stability around this shared code.

bq. If we do this can we also move out hbck version 1?

As HBCK2 tool will be freshly written, we can try to achieve this goal. I
think its great idea to move hbck1 to new repo as well. Though I think its
more involved with hbck1 as the existing code already uses what it can from
hbase-common and hbase-server etc. modules.

bq. How often does HBCK make decisions on how to implement a correction
based on some known functionality (e.g. a bug) in a specific version(s)
of HBase. Concretely, would HBCK need to make corrections to an HBase
installation that are specific to a subset of HBase 2.x.y versions that
may not be valid for other 2.x.y versions?

I see if this happens too often, compatibility metrics will be complicated.

Thanks,
Umesh


On Tue, Jul 24, 2018 at 10:27 AM Andrew Purtell  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.
>
> 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  wrote:
>
> > On Thu, Jul 19, 2018 at 2:09 PM Umesh Agashe
>  > >
> > 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
>

[DISCUSS] Separate Git Repository for HBCK2

[Umesh Agashe]

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?

Thanks,
Umesh

JIRA:  https://issues.apache.org/jira/browse/HBASE-19121.
Doc:
https://docs.google.com/document/d/1NxSFu4TKQ6lY-9J5qsCcJb9kZOnkfX66KMYsiVxBy0Y/edit?usp=sharing

Re: Welcome Chia-Ping Tsai to the HBase PMC

[Umesh Agashe]

Congratulations Chia-Ping!

On Sat, Sep 30, 2017 at 8:21 AM, Yu Li  wrote:

> Congratulations, Chia-Ping!
>
> Best Regards,
> Yu
>
> On 30 September 2017 at 15:38, Anoop John  wrote:
>
> > Congrats Chia-Ping  Welcome..
> >
> > -Anoop-
> >
> > On Sat, Sep 30, 2017 at 12:28 PM, Ashish Singhi  >
> > wrote:
> > > Congratulations, Chia-Ping.
> > >
> > > On Sat, Sep 30, 2017 at 3:49 AM, Misty Stanley-Jones  >
> > > wrote:
> > >
> > >> The HBase PMC is delighted to announce that Chia-Ping Tsai has agreed
> to
> > >> join
> > >> the HBase PMC, and help to make the project run smoothly. Chia-Ping
> > became
> > >> an
> > >> HBase committer over 6 months ago, based on long-running participate
> in
> > the
> > >> HBase project, a consistent record of resolving HBase issues, and
> > >> contributions
> > >> to testing and performance.
> > >>
> > >> Thank you for stepping up to serve, Chia-Ping!
> > >>
> > >> As a reminder, if anyone would like to nominate another person as a
> > >> committer or PMC member, even if you are not currently a committer or
> > PMC
> > >> member, you can always drop a note to priv...@hbase.apache.org to let
> > us
> > >> know!
> > >>
> > >> Thanks,
> > >> Misty (on behalf of the HBase PMC)
> > >>
> >
>

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Umesh Agashe]

Congratulations Misty!



On Fri, Sep 22, 2017 at 11:41 AM, Esteban Gutierrez 
wrote:

> Thats awesome! Congratulations, Misty!
>
>
>
> --
> Cloudera, Inc.
>
>
> On Fri, Sep 22, 2017 at 11:27 AM, Alexander Leblang <
> alex.lebl...@cloudera.com> wrote:
>
> > Congrats Misty! Well done!
> > On Fri, Sep 22, 2017 at 11:25 AM Wei-Chiu Chuang 
> > wrote:
> >
> > > Congrats! Misty!!
> > >
> > > On Fri, Sep 22, 2017 at 7:50 AM, Jimmy Xiang  wrote:
> > >
> > > > Congrats! Misty!!
> > > >
> > > > On Fri, Sep 22, 2017 at 7:16 AM, Pankaj kr 
> > wrote:
> > > >
> > > > > Congratulations Misty..!! :)
> > > > >
> > > > >
> > > > > -Pankaj-
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Andrew Purtell [mailto:apurt...@apache.org]
> > > > > Sent: Friday, September 22, 2017 3:08 AM
> > > > > To: d...@hbase.apache.org; user@hbase.apache.org
> > > > > Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
> > > > >
> > > > > At today's meeting of the Board, Special Resolution B changing the
> > > HBase
> > > > > project Chair to Misty Stanley-Jones was passed unanimously.
> > > > >
> > > > > Please join me in congratulating Misty on her new role!
> > > > >
> > > > > ​(If you need any help or advice please don't hesitate to ping me,
> > > Misty,
> > > > > but I suspect you'll do just fine and won't need it.)​
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > A very happy Hadoop contributor
> > >
> >
>

Re: [ANNOUNCE] New HBase committer Huaxiang Sun

[Umesh Agashe]

yay! Congratulations Huaxiang!

On Mon, Jun 19, 2017 at 12:30 PM, Sean Busbey  wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that
> Huaxiang Sun has accepted the PMC's invitation to become a committer
> on the project. We appreciate all of Huaxiang's great work thus far
> and look forward to continued involvement.
>
> Please join me in congratulating Huaxiang!
>