public inbox for
 help / color / mirror / Atom feed
From: Andrew Cagney <>
To: Elena Zannoni <>,
Cc: Phil Muldoon <>, Mark Wielaard <>
Subject: Re: Again the build is broken :(
Date: Fri, 24 Aug 2007 21:00:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Elena Zannoni wrote:
> Sure, the two things you mention are not mutually exclusive.
> However there is a cost to identifying broken builds too, and it seems 
> that Mark is drawing the
> short straw frequently, since he is usually the first to correct said 
> oversights. It takes away some
> of his time from development.
Quite frequently, during the American day, we encounter and quick fix 
similar issues (just today there was another "oops"), and we're 
successfully and co-operatively managing these hiccups through our IRC 
chatter and/or through bug reports and commits.

However, we do need to be careful. Both Pearly and Mark pick up what 
I'll call the night shift (from my tz pov) and so occasionally might be 
first to encounter a problem also encountered by this build system. 
There I think the most important thing is for us to be careful that we 
don't message an expectation that Pearly and/or Mark are some how 
expected to down-tools and focus all energies on getting it fixed.  As 
with us during the day, back-date the check-out for a few hours 'til 
things are resolved; for mark using mecurial, this is trivial.

Can I suggest:

- Moving the build farm's time to run just before US dawn so results are 
better timed for us waking up; or better ...

- setting up a test system that makes available results from individual 
commits and not fuzzy dates

- accept that an occasional build failure in the build farm does not 
require an immediate post about the sky falling; I for instance would 
only be concerned if the build failed consistently and for an identical 
reason across two work days; and then my first response is still going 
to be to fix it.


> I haven't suggested that you or anybody checks every combination
> before checking stuff in. What I have suggested is that, like we used 
> to do once upon a time, we
> stick with as few development platforms as we can get away with in 
> order to minimize the
> oversights. So if the platforms supported are FC6 and F7, let's stick 
> with those and make
> everybody's life easier. If somebody wants to add FC5 to the test 
> grid, please do so and contribute
> the tests results so that they can be uploaded. Any takers?

  reply	other threads:[~2007-08-24 21:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-24  5:51 Kris Van Hees
2007-08-24  8:16 ` Mark Wielaard
2007-08-24 11:12   ` Mark Wielaard
2007-08-24 11:47     ` Mark Wielaard
2007-08-24 12:34   ` Andrew Cagney
2007-08-24 14:26     ` Elena Zannoni
2007-08-24 14:39       ` Mark Wielaard
2007-08-24 15:17         ` Phil Muldoon
2007-08-24 16:14           ` Elena Zannoni
2007-08-24 21:00             ` Andrew Cagney [this message]
2007-08-28  0:19             ` Phil Muldoon
2007-08-24 16:44         ` Kris Van Hees
2007-08-26 21:21 Kris Van Hees

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).