gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [RT] Moving gump forward
Date Mon, 08 Mar 2004 21:51:32 GMT

In message <05b901c40526$1fe9d210$0100a8c0@tsws1>, "Adam R. B. Jack" writes:
>judging health, we had one gentleman go to the trouble of digging out the
>algorythm for FOG from Gumpy CVS, evaluating it, and submitting a JIRA entry
>(which I agree with, BTW). That is effort, that is motivation. The loss of
>"team pride" (maybe) of having their FOG factor halved was a motivator.

I had actually written a couple aborted emails (parts of which I cut and
pasted into the improvement issue report) about the topic over preceding
months that I never sent to the list because they sounded like I was
making mountains out of mole hills and adding unnecessary noise when Gump
committers were hard at work making more important improvements.  I'm sure
I sent a poorly articulated email about it around the time FOG was first
added to the generated results.  At any rate, it's been on my mind for a
while since I believe it's inevitable lots of folks are going to pay
attention to Gump because it's so handy.  The FOG factor halving just
reminded me of the topic and gave me a concrete example of why it can be 

>think we (as a group) keep overlooking one main thing. Gump is a social
>experiment but we keep using the techie's golden hammer -- more
>technology -- to try to solve it.
>In summary -- my point is we've not explored the social solutions to the
>Gumpmeister headache, and I'd love to hear other ideas on how we could
>leverage that.

I agree with what you said.  If everyone is paying attention to Gump,
then it matters little if you can't pin down exactly who's responsible
for a failure because everyone who gets a nag works toward identifying
the nature of the problem and coordinates with other projects to resolve
the problem.  Ultimately, Gump fosters cross-project cooperation.

>Perhaps we ought copy 'affected' projects on nags, so the recipient &
>those affected know who is affecting them. Nags are (right now) too
>personal/private & a team can quietly sit on them.

I think that would be very useful, but it could be limited
in some way so that code bases used by hundreds of projects (e.g.,
parts of commons) don't generate hundreds of nags.  Perhaps affected
projects would receive an abbreviated email and another one after
the problem is resolved.  Also, you don't want a cascade of emails
going out because of failures in multiple code bases and affected
projects.  So maybe a summary nag could go out to each project,
tailored to that project.  The summary would list all failures
in code bases that depend on the project and all failures in
code bases depended on by the project.  Actually for the "depended on"
code bases, it's probably better to list all dependencies and 
success or failure status of each because a code base can cause
a failure in a project and still have built successfully.  These
customized failure summaries would avoid the need to automatically
determine the exact source of a failure and whom to nag because
it presents humans with a list of possible places to start hunting.
Only if everybody ignores the emails does it fail to provide any
benefit.  If a small group of projects take an active interest, their
connections to other projects should propagate responsiveness in general
over time.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message