I say we don't worry about this. Use case is not worth the headache of
supporting it.

I don't think the potential benefits of inlining would be worth the overhead and
maintenance burden. It doesn't seem too hard to inline clean ASCII patches, even
to check for a maximum size before inlining. But I wouldn't like to have to fix
broken inlining of files with invalid chars, mixed line-endings, whatever.

If more people ask for attachments (below a maximum size), I'll try to implement it.

I did think about the case, what if the patches are large. But I think, *most* of
the patches are ASCII files and would not make up as huge attachments.

For people using text based email clients (like mutt), this would definitely be
an advantage. Also clients display the attached text files inline, so patch
review and responding back in the same thread with the quoted patch would be
easier.

We can go in for a consensus, if required. And it can also be setup as an
option in roundup which users can switch-on/off.

I'm not sure that attaching the files is good. They may be large, and they may
be harder to read in the email reader than in the web browser (at least, I
prefer to read them in the web browser - clicking on the link in the email ready
is really no big deal)

I subscribe to python-bugs list and follow the bugs discussion mostly through
the python-bugs email. I know many other developers do so as it faster than
keeping track through web interface.
The patches attached to bug-report are listed as Hyperlink in the email. It
would be better and enormously helpful if the patches are listed inline instead
or as attachments in the email. I think, python-bugs while using sf.net had it
like that and when moving to roundup this feature changed.