From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Ted Zlatanov <tzz@lifelogs.com>
Cc: emacs-devel@gnu.org
Subject: Re: eshell-defgroup. Do we really need this?
Date: Tue, 05 Aug 2008 17:20:00 +0900 [thread overview]
Message-ID: <87vdyfg9fz.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <86vdygzku5.fsf@lifelogs.com>
Ted Zlatanov writes:
> I guess I come from a background of sysadmin, where things that can go
> wrong will, so I'd rather not assume this. I've had enough experience
> with "this should never happen" happening at 3 AM.
That's just an argument for never doing any testing, since *any* test
could fail due to a flaky memory chip.
> What I'm trying to help provide is a proactive mechanism.
Then look elsewhere than buildbot, which is just an attempt to speed
up the reaction. A proactive solution would be to convince the Scons
people to join GNU.<wink>
> SJT> XEmacs and SXEmacs see *way* fewer "broken build" reports, and when
> SJT> we do, the response is almost always that the responsible developer
> SJT> pipes up with "oops, my bad, fixed" within 24 hours. I've *never*
> SJT> seen the kind of "Did you wait until the goat died? You can't
> SJT> start the build before the sacrificial goat is dead!" threads that
> SJT> are so common on emacs-devel.
>
> Well, maybe that will change when we can identify the change that broke
> the builds. I am not trying to change social dynamics, regardless.
That wasn't a diagnosis, that was a description of a painful symptom.
We've got a patient with a migraine, and he's *not* holding a hammer.
That is, this thread was occasioned by breakage that happened to *one*
person, and we do not yet know what caused that problem. Since the
details the OP has since given "shouldn't happen" the maintainers are
almost certainly going to table the matter and wait for more
evidence. The buildbots won't help with that.
What buildbots can do is point out the easy ones quickly. Note that
Alan used several methods to ensure a "clean" build; none of them
worked. If there were a buildbot for his platform and configuration,
then you could say, "OK, bot is green, so let's see what is 'dirty'
about your environment."
> My suggestion was to look for 5 or more broken build reports from
> buildbots in the community.
I think you vastly overestimate the number of buildbots that will be
forthcoming.
> I could go on, but the point is a broken build from a single system
> can be caused by too many factors external to the build process.
Surely you can distinguish between the number of ways to go wrong and
the probability of going wrong? The evidence I've seen in the Python
project is that nobody has ever complained in about 2 years of running
buildbots of spurious reports. The vast majority of red bots are bugs
in the Python build or regressions.
next prev parent reply other threads:[~2008-08-05 8:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-29 22:27 eshell-defgroup. Do we really need this? Alan Mackenzie
2008-07-31 19:17 ` Ted Zlatanov
2008-07-31 19:18 ` Lennart Borgman (gmail)
2008-08-01 15:34 ` Ted Zlatanov
2008-08-01 17:08 ` Romain Francoise
2008-08-01 20:30 ` Ted Zlatanov
2008-08-02 4:18 ` Stephen J. Turnbull
2008-08-04 16:34 ` Ted Zlatanov
2008-08-04 17:49 ` Stephen J. Turnbull
2008-08-04 18:38 ` Ted Zlatanov
2008-08-05 8:20 ` Stephen J. Turnbull [this message]
2008-08-05 13:57 ` buildbots (was: eshell-defgroup. Do we really need this?) Ted Zlatanov
2008-08-05 20:25 ` Stephen J. Turnbull
2008-08-08 15:26 ` place to send build failure reports? (was: buildbots) Ted Zlatanov
2008-08-08 15:58 ` place to send build failure reports? Chong Yidong
2008-08-03 19:02 ` eshell-defgroup. Do we really need this? Romain Francoise
2008-08-04 16:31 ` Ted Zlatanov
2008-08-01 16:10 ` Progress: " Alan Mackenzie
2008-08-07 19:25 ` Stefan Monnier
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vdyfg9fz.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=tzz@lifelogs.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.