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