Re: Commit Rules

[Alan Conway <ac...@redhat.com>]

On Mon, 2007-04-30 at 16:15 -0400, Rajith Attapattu wrote:
> Hi Tomas,
> 
> Like the others pointed out, the golden rule is that your commits doesn't
> break the build.
> At the minimum there shouldn't be any compilation errors.
> But it would be great if all the unit tests pass too. (well there is the -
> Dmaven.test.skip to get around that).

I strongly disagree. At a minimum _all_ tests: unit, system, and interop
when we have them must pass after _every_ commit unless there's some
compelling and unusual situation that makes it impossible AND there are
people actively working to resolve that unusual situation.

You can take any shortcuts you like provided you don't get caught :) In
particular if you're working on shared stuff like specs or gentools you
need to be sure that *all* the projects still work after your changes.
There have been several occasions where specs changes with Java commits
broke the C++ and/or python builds.

If that's too awkward or time consuming then document, optimize or
redesign the test harness till it is usable. Tests deserve as much
attention to quality as production code - don't forget we're the ones
who suffer if they suck.

I look forward to having cruise control and automatic public humiliation
for build breakage.

Cheers,
Alan.

Re: Commit Rules

[Rajith Attapattu <ra...@gmail.com>]

LOL, I have to say I agree with Alan all the way.
Now I never took any short cuts :) , well ....maybe once or twice.

But yes changes to your java broker shouldn't break the c++ client... thats
a very good point.
One of the biggest selling points we have is the cross language
interoperability. So we need to ensure this all the time.

Regards,

Rajith.

On 4/30/07, Alan Conway <ac...@redhat.com> wrote:
>
> On Mon, 2007-04-30 at 16:15 -0400, Rajith Attapattu wrote:
> > Hi Tomas,
> >
> > Like the others pointed out, the golden rule is that your commits
> doesn't
> > break the build.
> > At the minimum there shouldn't be any compilation errors.
> > But it would be great if all the unit tests pass too. (well there is the
> -
> > Dmaven.test.skip to get around that).
>
> I strongly disagree. At a minimum _all_ tests: unit, system, and interop
> when we have them must pass after _every_ commit unless there's some
> compelling and unusual situation that makes it impossible AND there are
> people actively working to resolve that unusual situation.
>
> You can take any shortcuts you like provided you don't get caught :) In
> particular if you're working on shared stuff like specs or gentools you
> need to be sure that *all* the projects still work after your changes.
> There have been several occasions where specs changes with Java commits
> broke the C++ and/or python builds.
>
> If that's too awkward or time consuming then document, optimize or
> redesign the test harness till it is usable. Tests deserve as much
> attention to quality as production code - don't forget we're the ones
> who suffer if they suck.
>
> I look forward to having cruise control and automatic public humiliation
> for build breakage.
>
> Cheers,
> Alan.
>
>

Re: Commit Rules

[John O'Hara <jo...@gmail.com>]

Buy that man a beer.

On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
>
> On Mon, 2007-04-30 at 16:15 -0400, Rajith Attapattu wrote:
> > Hi Tomas,
> >
> > Like the others pointed out, the golden rule is that your commits
> doesn't
> > break the build.
> > At the minimum there shouldn't be any compilation errors.
> > But it would be great if all the unit tests pass too. (well there is the
> -
> > Dmaven.test.skip to get around that).
>
> I strongly disagree. At a minimum _all_ tests: unit, system, and interop
> when we have them must pass after _every_ commit unless there's some
> compelling and unusual situation that makes it impossible AND there are
> people actively working to resolve that unusual situation.
>
> You can take any shortcuts you like provided you don't get caught :) In
> particular if you're working on shared stuff like specs or gentools you
> need to be sure that *all* the projects still work after your changes.
> There have been several occasions where specs changes with Java commits
> broke the C++ and/or python builds.
>
> If that's too awkward or time consuming then document, optimize or
> redesign the test harness till it is usable. Tests deserve as much
> attention to quality as production code - don't forget we're the ones
> who suffer if they suck.
>
> I look forward to having cruise control and automatic public humiliation
> for build breakage.
>
> Cheers,
> Alan.
>
>