Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FVws3xwuWHI198WFPYuGh1GmOsGRAYsN6/a9V3nmGiDzearm58p7ba3BwgLXuEjhPKn5WxO6miTwj6CiNgk3y3fVrEg5X1E6Je6HkTWNTSIRUwhlB3PwP+3Je8MCPgyOpCLhRZ1IikUWIg5UY7mmgVUSVOZB866ISQiydeOFd1o=
Message-ID: <510143ac0803020057p623935e6p6b2433ac83405506@mail.gmail.com>
Date: Sun, 2 Mar 2008 10:57:59 +0200
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: infrastructure-dev@apache.org
Subject: Re: [scm] Use case: Continuous integration
In-Reply-To: <25aac9fc0803011415x21b27884i6d9276dff368f1e8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <510143ac0803010406n52fb6c8bm5b7d75e100757ce@mail.gmail.com>
	 <25aac9fc0803010540s4b61a57fv5c277885d0755ab0@mail.gmail.com>
	 <510143ac0803010557h47dd8af9t6634f9a7b845d631@mail.gmail.com>
	 <25aac9fc0803011415x21b27884i6d9276dff368f1e8@mail.gmail.com>

Hi,

On Sun, Mar 2, 2008 at 12:15 AM, sebb <sebbaz@gmail.com> wrote:
>  Not entirely sure why one should care about temporary build failures,
>  unless one is trying to find out which committers are not adhering to
>  the rules.

In many case developer time is much more valuable than computing time,
so a CI system that can quickly and accurately point out a build
failure can easily save time and improve productivity.

That may not be a key priority for the ASF itself, but it can be quite
valuable to many companies that have people actively working on Apache
projects. If they provide the required CI machinery, what can we do on
the SCM side to enable optimum usage of such resources?

>  Also, it seems to me that this may not scale well - the average time
>  between commits can easily exceed the time to perform a build.

A reasonable system would of course queue the change notifications and
process them one at a time. The average commit frequency will hardly
overload a decent CI server, and any backlog acquired during commit
peaks will probably be soon resolved.

This is probably also something that should be taken into account with
frequently running pull-based CI servers as well. At least I've seen
complaints about multiple CI builds stacking up when the build time
exceeds the poll frequency.

BR,

Jukka Zitting