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 sebbaz@gmail.com designates
 209.85.200.169 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=wtQmDWykSrDVVExjg62WtxrNrIBVtygidJDYWK4xhdcJVi73POGXxpmhEZRflNA/LR1tORKEOAXlrifmhJKC5LlhGEPoAXhhXqwfIWM2hd5d3kZEzSqlyJxm1ffZAn5V93nn+szCz+LztwwcZEzOL1PVIxbchznRvGC50HUzRC0=
Message-ID: <25aac9fc0803020331u6d2880a0ja74a8c86923e13ce@mail.gmail.com>
Date: Sun, 2 Mar 2008 11:31:41 +0000
From: sebb <sebbaz@gmail.com>
To: infrastructure-dev@apache.org
Subject: Re: [scm] Use case: Continuous integration
In-Reply-To: <510143ac0803020057p623935e6p6b2433ac83405506@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>
	 <510143ac0803020057p623935e6p6b2433ac83405506@mail.gmail.com>

On 02/03/2008, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.

Surely that is only of use if the build failure has not already been
resolved by a later commit?  For example, it's quite easy accidentally
to omit a new file from a commit; this will normally be spotted
quickly afterwards, and then the missing file can be committed.

Not ideal of course if someone else happens to update in between, but
not really a big problem either as it will be immediately obvious when
the CI system is checked and the later build is OK.

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

Or exceeds the pushed commit messages ...

>  BR,
>
>
>  Jukka Zitting
>