qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Commit Rules
Date Thu, 10 May 2007 00:00:20 GMT
Buy that man a beer.

On 01/05/07, Alan Conway <aconway@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message