On Dec 8,  8:22am, "Blair Sadewitz" wrote:
}
} Weighing the pros and cons, I think it might be best to create a
} bulkier, "rich-text" html-source-changes list.  However, we don't want
} to end up exponentially increasing the number of lists we have
} according to each feature set people lobby for. ;)

     So far only one person has said they don't like the idea.  Whereas
a bunch of people both inside and outside of the project has said they
do like the idea.  I don't think one naysayer should hold things up.

     One concern for me is that length of the URLs.  Here is one
example:

http://cvsweb.netbsd.org/bsdweb.cgi/src/share/man/man9/ctxsw.9.diff?r1=1.21&r2=1.22&f=h

Notice how it wraps.  With the terminal program that I'm using, I can
just point at an URL, right click, and the top item is "Launch this
URL".  I can't do that when the URL wraps.  However, for people using
web browsers to read their e-mails (I include things like Outlook
Express in this category), the URL length won't be a problem.

     Another thing to consider is messages with multiple commits.  With
things like gcc imports, a single message can have more then 1,000
items.  We probably don't want to add 1,000 diffs to a message.  Also,
when new files are added, they can be fairly lengthy.  The question is
what should be the cutoff point in adding diffs to messages?  Some
ideas are:

- no diffs for messages with multiple files
- diffs for messages with 5 or less files
- diffs for the first 5 files for messages with multiple files

- don't include new files in messages
- only include the first X number of lines
- skip the licence at the beginning of the file and then include X lines

}-- End of excerpt from "Blair Sadewitz"