Re: Testing HBase packaging changes

2016-03-14 Thread Ted Yu
On top of letting unit test suite pass,
running IntegrationTestBigLinkedList (and integration test related to the
feature you modify) regularly is a good practice such that the changes do
not introduce regression.

FYI

On Mon, Mar 14, 2016 at 2:15 PM, Bryan Beaudreault  wrote:

> Hello,
>
> We've been using CDH community for a few years now, but have reached the
> point where we want to be able to do some development and backporting
> upstream. We'd like to keep the base CDH packaging for consistency, but
> have come up with some automation around building CDH from source RPM, with
> our patches applied.
>
> I realize this starts to get into the territory of self-support, and we're
> ready for that in the areas we plan to work (mostly around
> reporting/monitoring, for now). But I'd like to know if anyone has any best
> practices for testing that your build of HBase is up to snuff?
>
> Are the built in unit tests enough? Do you run YCSB? PerformanceEval?
> Something else?
>
> While we will of course be careful with testing and stressing our own
> changes, I'm also just wanting to make sure that the we are hitting all the
> right places to catch artifacts from the build process or missed upstream
> issues.
>
> Thanks!
>


Testing HBase packaging changes

2016-03-14 Thread Bryan Beaudreault
Hello,

We've been using CDH community for a few years now, but have reached the
point where we want to be able to do some development and backporting
upstream. We'd like to keep the base CDH packaging for consistency, but
have come up with some automation around building CDH from source RPM, with
our patches applied.

I realize this starts to get into the territory of self-support, and we're
ready for that in the areas we plan to work (mostly around
reporting/monitoring, for now). But I'd like to know if anyone has any best
practices for testing that your build of HBase is up to snuff?

Are the built in unit tests enough? Do you run YCSB? PerformanceEval?
Something else?

While we will of course be careful with testing and stressing our own
changes, I'm also just wanting to make sure that the we are hitting all the
right places to catch artifacts from the build process or missed upstream
issues.

Thanks!