Re: eshell-defgroup. Do we really need this?

[Stephen J. Turnbull]

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.