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

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 4 Aug 2008 17:49:01 +0000 (UTC) "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
SJT> Romain's right, you don't need confirmation.  If a clean build breaks,
SJT> it's broke.  What to do about it is another question.
>> 
>> Builds can break for many reasons, some local (e.g. disk full).  Why
>> bother many people with a false report?

SJT> Because they don't happen much in practice on well-maintained 'bots,
SJT> which is what you want.

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.

>> It would condition them to ignore truly broken builds.

SJT> Excuse me, but isn't the problem that they already do??  (Yes, I know
SJT> that's specious.  It's still true.  Fix the bigger problem first. :-)

No.  You're confusing issues.  What I'm trying to help provide is a
proactive mechanism.  The current broken build detection is reactive:
users report busted builds or developers find out when they do a build.
So broken builds just don't emerge as a problem quickly.

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.
It's neither my target nor my interest, and the Emacs maintainers should
address that side of the process.

SJT> If there is a 'bot spewing because of disk full, sentence the 'bot
SJT> owner to some public service like reading the entire Collected Works
SJT> of Richard Stallman (including the source code to all his programs)
SJT> out loud at the main gate of Microsoft.

SJT> If and when the rate of disk full reports reaches 10% of the rate of
SJT> genuine breakage, start forwarding them as bug reports to buildbot.

I was giving an example.  By definition you can't anticipate every
failure mode, so I'd rather not assume builds will always work.  Here's
some other causes: transient network outage, missing/broken libraries,
misconfiguration, race conditions, OS limitations, ACLs, memory/CPU
usage limits, swap space/process table/memory exhaustion, power outage,
filesystem corruption...  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.

SJT> Also, it shouldn't be hard to construct a filter that recognizes
SJT> such and pings the 'bot owner.  If you have access to the Mailman
SJT> pipeline, it can easily be installed in the list config (ie, without
SJT> risk to other Mailman lists) and set up to ping only interested
SJT> parties, and not forward it to the list.

My suggestion was to look for 5 or more broken build reports from
buildbots in the community.  I think that's better than the workarounds
you suggest, because it's not dependent on anything other than agreement
between separate systems.  Your solution recognizes potential failure
modes *after* they occur and works backwards after the annoyance has
already happened.

Ted