[plt-dev] Fwd: [DrDr] R17971 (timeout 1) (unclean 7) (stderr 17) (changes 71)

On Feb  4, Jay McCarthy wrote:
> Would you like DrDr to send email like this to plt-dev?
> 
> Here are the features:
> 
> 1) No email if there are no problems
> 
> 2) Reports the following problem categories: timeouts, unclean exits,
> stderr output, and changes.
> 
> 3) It shows the first two of those that have problems, so if timeouts
> = 0, then it just shows unclean and stderr. If stderr is also 0, then
> it will also show changes. This keeps the email size down and
> prioritizes certain kinds of errors.
> 
> 4) It may look ugly to have http://... everywhere, but it is a way of
> getting most email clients to show a link without sending HTML mail.
> Those links go right to the file to diagnose the problem.
> 
> What do you think?

This is an extremely bad idea.

* Constant nag emails are a very effective way to have them ignored.

* This list is not a place for this kind of traffic -- you'll be
  harassing people who have no control over what happens in svn, and a
  reasonable reaction would be to unsubscribe.  (Or complain to the
  moderator to block the offending spam source.)

* Even if you make it post to a smaller group of people (eg, all
  committers), you're still doing a lot of nag which will get
  ignored.  Attempts to create social pressure are not going to work
  either: what happens when you have some deadline/class/whatever, and
  there happens to be a bug which you can tend to only after a week.
  In the meanwhile, everyone got those spams for each an every
  commit.  (Also, even if you fix a bug within an hour, and during
  that hour someone did 20 commit, that still looks like it implied
  one message per commit.)

I see two ways to make it work:

* No constant nagging -- just send emails when there's a change in a
  file's status.  You can also have a page somewhere with open
  issues and how many days a problem was not fixed.

* A better way is to email just the responsible parties.  There's not
  even a point in splitting the report up, since failures are likely
  to be related to the change that caused that build.  The code in the
  meta collection is close to giving you that, and I can add that
  interface if you want to do that.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!