qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: Commit Rules
Date Tue, 01 May 2007 16:17:38 GMT
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.



On 4/30/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.

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