Hi all;

I created two jiras:
1) HBASE-4712 is for documenting the standard way for writing tests. Not
rocket science, but it will help to keep a certain level of quality. Please
have a look at it & feel free to comment.
2) HBASE-4737 is for the split; as discussed two weeks ago. There is a
split proposal. I will apply this split this week-end or monday, don't
hesitate to provide a feedback before (or after if necessary :-). I tested
the parallelization within surefire for the small tests, it seems to work
quite well.

Don't forget that the idea is to run only small & medium on the developer
machine by default. This will make the sub-tests-suite runs under 30
minutes, but the selection is important if we don't want to kill the
pre-patch machine with defects that could have been detected before.

I will provide a script to test this before the 'hard' surefire push.  This
script also allow to launch two maven instances in parallel. Still beta,
but can be useful. I will attach it to HBASE-4737 when the pre patch
machine validates my patch on pom.xml :-)

Cheers,

Nicolas

On Thu, Nov 3, 2011 at 9:32 AM, N Keywal <[EMAIL PROTECTED]> wrote:
> I created two jiras:
> 1) HBASE-4712 is for documenting the standard way for writing tests. Not
> rocket science, but it will help to keep a certain level of quality. Please
> have a look at it & feel free to comment.
>

Commented.  It looks really good.
> 2) HBASE-4737 is for the split; as discussed two weeks ago. There is a
> split proposal. I will apply this split this week-end or monday, don't
> hesitate to provide a feedback before (or after if necessary :-). I tested
> the parallelization within surefire for the small tests, it seems to work
> quite well.
>
> Don't forget that the idea is to run only small & medium on the developer
> machine by default. This will make the sub-tests-suite runs under 30
> minutes, but the selection is important if we don't want to kill the
> pre-patch machine with defects that could have been detected before.
>

You thinking patch-build should not run the full suite?
> I will provide a script to test this before the 'hard' surefire push.  This
> script also allow to launch two maven instances in parallel. Still beta,
> but can be useful. I will attach it to HBASE-4737 when the pre patch
> machine validates my patch on pom.xml :-)
>

Good stuff,
St.Ack

> > 2) HBASE-4737 is for the split; as discussed two weeks ago. There is a
> > split proposal. I will apply this split this week-end or monday, don't
> > hesitate to provide a feedback before (or after if necessary :-). I
> tested
> > the parallelization within surefire for the small tests, it seems to work
> > quite well.
> >
> > Don't forget that the idea is to run only small & medium on the developer
> > machine by default. This will make the sub-tests-suite runs under 30
> > minutes, but the selection is important if we don't want to kill the
> > pre-patch machine with defects that could have been detected before.
> >
>
> You thinking patch-build should not run the full suite?
>
>
I was thinking about the hbase-book, chapter "13.7 submitting patch". Today
it says; " Make sure unit tests pass locally before submitting the patch.".
It could become something as: "Make sure unit tests pass locally before
submitting the patch. For large or risky patches, run as well the
integration/large tests suite before submitting".

On Thu, Nov 3, 2011 at 9:53 AM, N Keywal <[EMAIL PROTECTED]> wrote:

> > > 2) HBASE-4737 is for the split; as discussed two weeks ago. There is a
> > > split proposal. I will apply this split this week-end or monday, don't
> > > hesitate to provide a feedback before (or after if necessary :-). I
> > tested
> > > the parallelization within surefire for the small tests, it seems to
> work
> > > quite well.
> > >
> > > Don't forget that the idea is to run only small & medium on the
> developer
> > > machine by default. This will make the sub-tests-suite runs under 30
> > > minutes, but the selection is important if we don't want to kill the
> > > pre-patch machine with defects that could have been detected before.
> > >
> >
> > You thinking patch-build should not run the full suite?
> >
> >
> I was thinking about the hbase-book, chapter "13.7 submitting patch". Today
> it says; " Make sure unit tests pass locally before submitting the patch.".
> It could become something as: "Make sure unit tests pass locally before
> submitting the patch. For large or risky patches, run as well the
> integration/large tests suite before submitting".
>

+1

We might want to qualify 'large' as spanning X classes (4+?) so people have
something to go by. However, this doesn't need to be a hard and fast rule
as jenkins should be running the entire suite.

--
-------------------
Jesse Yates
240-888-2200
@jesse_yates

With help from Giri, we have patch testing for TRUNK.
I think all patches for TRUNK (0.92 included in the near future since
they're quite close) should go through HadoopQA, i.e. patch testing.

The rationale is that contributor may not have hardware + OS (Ubuntu)
combination that Jenkins uses.
Certain timing related issues would be exposed on Jenkins, as previous
incidents have shown.

For patches targeting 0.90.x, we rely on contributor/committer to run test
suite.

Cheers

On Thu, Nov 3, 2011 at 9:53 AM, N Keywal <[EMAIL PROTECTED]> wrote:

> > > 2) HBASE-4737 is for the split; as discussed two weeks ago. There is a
> > > split proposal. I will apply this split this week-end or monday, don't
> > > hesitate to provide a feedback before (or after if necessary :-). I
> > tested
> > > the parallelization within surefire for the small tests, it seems to
> work
> > > quite well.
> > >
> > > Don't forget that the idea is to run only small & medium on the
> developer
> > > machine by default. This will make the sub-tests-suite runs under 30
> > > minutes, but the selection is important if we don't want to kill the
> > > pre-patch machine with defects that could have been detected before.
> > >
> >
> > You thinking patch-build should not run the full suite?
> >
> >
> I was thinking about the hbase-book, chapter "13.7 submitting patch". Today
> it says; " Make sure unit tests pass locally before submitting the patch.".
> It could become something as: "Make sure unit tests pass locally before
> submitting the patch. For large or risky patches, run as well the
> integration/large tests suite before submitting".
>

Agreed,  patch testing is a great feature to be used as much as possible!

On Thu, Nov 3, 2011 at 6:04 PM, Ted Yu <[EMAIL PROTECTED]> wrote:

> With help from Giri, we have patch testing for TRUNK.
> I think all patches for TRUNK (0.92 included in the near future since
> they're quite close) should go through HadoopQA, i.e. patch testing.
>
> The rationale is that contributor may not have hardware + OS (Ubuntu)
> combination that Jenkins uses.
> Certain timing related issues would be exposed on Jenkins, as previous
> incidents have shown.
>
> For patches targeting 0.90.x, we rely on contributor/committer to run test
> suite.
>
> Cheers
>
> On Thu, Nov 3, 2011 at 9:53 AM, N Keywal <[EMAIL PROTECTED]> wrote:
>
> > > > 2) HBASE-4737 is for the split; as discussed two weeks ago. There is
> a
> > > > split proposal. I will apply this split this week-end or monday,
> don't
> > > > hesitate to provide a feedback before (or after if necessary :-). I
> > > tested
> > > > the parallelization within surefire for the small tests, it seems to
> > work
> > > > quite well.
> > > >
> > > > Don't forget that the idea is to run only small & medium on the
> > developer
> > > > machine by default. This will make the sub-tests-suite runs under 30
> > > > minutes, but the selection is important if we don't want to kill the
> > > > pre-patch machine with defects that could have been detected before.
> > > >
> > >
> > > You thinking patch-build should not run the full suite?
> > >
> > >
> > I was thinking about the hbase-book, chapter "13.7 submitting patch".
> Today
> > it says; " Make sure unit tests pass locally before submitting the
> patch.".
> > It could become something as: "Make sure unit tests pass locally before
> > submitting the patch. For large or risky patches, run as well the
> > integration/large tests suite before submitting".
> >
>

I'll put together a book patch and have you guys comment on it before it
goes in.
On 11/3/11 12:56 PM, "Jesse Yates" <[EMAIL PROTECTED]> wrote:

>On Thu, Nov 3, 2011 at 9:53 AM, N Keywal <[EMAIL PROTECTED]> wrote:
>
>> > > 2) HBASE-4737 is for the split; as discussed two weeks ago. There
>>is a
>> > > split proposal. I will apply this split this week-end or monday,
>>don't
>> > > hesitate to provide a feedback before (or after if necessary :-). I
>> > tested
>> > > the parallelization within surefire for the small tests, it seems to
>> work
>> > > quite well.
>> > >
>> > > Don't forget that the idea is to run only small & medium on the
>> developer
>> > > machine by default. This will make the sub-tests-suite runs under 30
>> > > minutes, but the selection is important if we don't want to kill the
>> > > pre-patch machine with defects that could have been detected before.
>> > >
>> >
>> > You thinking patch-build should not run the full suite?
>> >
>> >
>> I was thinking about the hbase-book, chapter "13.7 submitting patch".
>>Today
>> it says; " Make sure unit tests pass locally before submitting the
>>patch.".
>> It could become something as: "Make sure unit tests pass locally before
>> submitting the patch. For large or risky patches, run as well the
>> integration/large tests suite before submitting".
>>
>
>+1
>
>We might want to qualify 'large' as spanning X classes (4+?) so people
>have
>something to go by. However, this doesn't need to be a hard and fast rule
>as jenkins should be running the entire suite.
>
>--
>-------------------
>Jesse Yates
>240-888-2200
>@jesse_yates

> From: Ted Yu <[EMAIL PROTECTED]>

> I think all patches for TRUNK (0.92 included in the near future since
> they're quite close) should go through HadoopQA, i.e. patch testing.
> 
> The rationale is that contributor may not have hardware + OS (Ubuntu)
> combination that Jenkins uses.
> Certain timing related issues would be exposed on Jenkins, as previous
> incidents have shown.
+1

Jenkins aka Hudson is a bastard. He often turns up timing issues impossible to reproduce locally.
 
Best regards,
   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
----- Original Message -----
> From: Ted Yu <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc:
> Sent: Thursday, November 3, 2011 10:04 AM
> Subject: Re: unit tests improvement
>
> With help from Giri, we have patch testing for TRUNK.
> I think all patches for TRUNK (0.92 included in the near future since
> they're quite close) should go through HadoopQA, i.e. patch testing.
>
> The rationale is that contributor may not have hardware + OS (Ubuntu)
> combination that Jenkins uses.
> Certain timing related issues would be exposed on Jenkins, as previous
> incidents have shown.
>
> For patches targeting 0.90.x, we rely on contributor/committer to run test
> suite.
>
> Cheers
>
> On Thu, Nov 3, 2011 at 9:53 AM, N Keywal <[EMAIL PROTECTED]> wrote:
>
>>  > > 2) HBASE-4737 is for the split; as discussed two weeks ago. There
> is a
>>  > > split proposal. I will apply this split this week-end or monday,
> don't
>>  > > hesitate to provide a feedback before (or after if necessary :-).
> I
>>  > tested
>>  > > the parallelization within surefire for the small tests, it seems
> to
>>  work
>>  > > quite well.
>>  > >
>>  > > Don't forget that the idea is to run only small & medium
> on the
>>  developer
>>  > > machine by default. This will make the sub-tests-suite runs under
> 30
>>  > > minutes, but the selection is important if we don't want to
> kill the
>>  > > pre-patch machine with defects that could have been detected
> before.
>>  > >
>>  >
>>  > You thinking patch-build should not run the full suite?
>>  >
>>  >
>>  I was thinking about the hbase-book, chapter "13.7 submitting
> patch". Today
>>  it says; " Make sure unit tests pass locally before submitting the
> patch.".
>>  It could become something as: "Make sure unit tests pass locally
> before
>>  submitting the patch. For large or risky patches, run as well the
>>  integration/large tests suite before submitting".
>>
>