On Jan 27, 2008 10:25 PM, Alexey Verkhovsky <alexey.verkhovsky / gmail.com> wrote:
> On Jan 27, 2008 4:59 PM, Sam Ruby <rubys / intertwingly.net> wrote:
> > So... the trick is to only include packages for which there are
> > identified people with the interest and bandwidth to keep on top of the
> > issues found.
>
> Exactly. In other words, committers should say "yes, we want a
> continuous build, we want to be annoyed by failed build notices in our
> mailboxes, and we will fix it when it breaks". Otherwise, you end up
> with a permanently broken build which costs quite a bit of effort to
> run, and adds little value to the project.
>
> If there is a commitment like that, I would volunteer to run that
> build in a heartbeat.
>

I was running something similar for 1.8 and 1.9 build of Ruby
internally at your office.

A few weeks back just turned it off since was annoyed by the constant
warns of FAILED BUILD warning we got.

Don't want to mention that was on a Linux box, the Windows build
always had 3 to 20 errors or failures all the time, that should be
considered safe (or good) even with them.

The complexity and the time it takes run a complete build/test
procedure as pre-commit hook can make the life of the commiters a bit
painful, but i think should be standard rule.

Just my comments.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams