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

Agreed. Send this email to the committer who triggered the change. 


On Feb 5, 2010, at 2:50 AM, Eli Barzilay wrote:

> 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!
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev