Mailing-List: contact qpid-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: qpid-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of john.r.ohara@gmail.com
 designates 64.233.162.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=hXGb1mM7ypAYg+YinWr0wZZ8T9krfQW4Kofg7aoIs9quWwX4N4JAUenj3nSJnBMmLtuitNPtQiLP5cCW3XpA9xgw0w/yAzxogLB3HPKWbJtV6pDc2XAT3oPpkcAvqdctOHMxT1RjolgLD+oZqo9s6ZD98U/E7qXXbdiYC6O+Fs8=
Message-ID: <1194ab690705091700l467261d5jbdd76c4c58e7d74e@mail.gmail.com>
Date: Thu, 10 May 2007 01:00:20 +0100
From: "John O'Hara" <john.r.ohara@gmail.com>
To: qpid-dev@incubator.apache.org
Subject: Re: Commit Rules
In-Reply-To: <1177983560.16677.73.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_163354_9858352.1178755220282"
References: <1177608248.3714.25.camel@localhost.localdomain>
	 <-6723344454111355226@unknownmsgid>
	 <b9472b590704290202y464e6c2cta099a0f44e6de44f@mail.gmail.com>
	 <f5f5e0730704301315xbd3da83q639f2fae7d6446d5@mail.gmail.com>
	 <1177983560.16677.73.camel@localhost.localdomain>

------=_Part_163354_9858352.1178755220282
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.
>
>

------=_Part_163354_9858352.1178755220282--