attaching or inlining? what to do when you're stuck with a stupid mail client???[Ay

[Geoff Thorpe]

On October 9, 2003 10:54 pm, Dimitrie O. Paun wrote:
> On October 9, 2003 09:58 pm, Geoff Thorpe wrote:
> > look/feel/use, like "wine-cvs". I would have personally thought that
> > attachments make more sense, because separating patches from text can
> > be ambiguous and it's not as easy to send multiple patches (eg. when
> > submitting two alternative patches?)
>
> It is strongly discouraged to send multiple patches. It has been
> discussed before multiple times, please search the archives. This is

The submission and processing of patches is not something totally alien to 
me, though the specific history and conclusions reached w.r.t. wine mail 
lists is. That said, you needn't crusade the inlining argument by 
dispatching me to the list archives about whether multiple patches are 
"discouraged" or not. Email, attachments, patches, and mail-lists are 
tools, not religions - hence any filter, such as that which we are 
discussing, should be there to help people receive what is easiest for 
them to use and not to stuff dogma down their throats. If I have three 
small alternative fixes to the same file, I will send an email explaining 
the situation with the three patches attached - not even Linus Torvalds 
would get far in convincing me that this is "Wrong(tm)". The point is, 
how can we (Shachar in particular) utilise a bit of perl tech in the mail 
server to make this easier for you, Alexandre, and others who have 
particular requirements/preferences/etc, whilst tolerating as many 
different "styles" of submission? This is surely the point, no?

> not something new, it has been discussed in other places (like the
> linux-kernel), multiple times, and every time we reach the same
> conclusion: the ideal situation is to have the patches inlined (patch
> takes are of extracting it just fine). The next best thing is
> attachment as text/plain, but not nearly as desirable as inline
> patches.

Anyway, I appreciate your point, but I personally maintain (ie. my 
opinion, for what (little) it's worth) that attachments are the best 
means by which to attach files to emails - without line wrapping, and 
with suitable MIME types to allow proper handling (my mailer will 
pretty-print attachments that look like patches, for example). Also, it 
will be easier for a mail filter to inline an attached text/plain file 
than to extract and attach inlined patches. In many mail clients, the 
email itself is not readily accessible as a raw file for piping through 
an appropriate cmd-line - on the other hand, the attachments are often 
neatly listed, extension/mime-type registered *as* patches, and even 
drag-n-droppable to CVS/diff tools. The primary (valid) objection to this 
is that "MUAs do it inconsistently so that it is too unreliable", but 
that is one of the reasons for embellishing the list-server with a filter 
like what we're suggesting.

The conclusions you refer to about patch submissions in the past have, 
presumably, centred around the premise that you need to standardise it 
because WYSIWTG (what you send is what they get). In that case, I agree 
that you are forced to put rules/standards in place to avoid chaos. But 
right now we are discussing a filter for the express purpose of being 
more tolerant in what is accepted, and more helpful/consistent in what is 
generated. I happen to think this makes more sense than forcing people 
through a dedicated patch/ticket management system, yet has many of the 
same advantages of abandoning traditional mail-lists (eg. you have less 
scope to "get it wrong"). BTW: another example - we could perhaps detect 
context diffs and, as with emails that don't satisfy any filter rules, 
prepend some banner text to the email body noting that the patch seems to 
be of an inappropriate format and should be resubmitted as a unified 
diff. Alexandre and the rest of us could simply ignore such postings 
without passing any comment, the submitter will see the bannered post 
turn up soon enough and can resubmit something better.

> > preferences. Then again, if the filter takes place prior to mail-list
> > processing maybe just splitting the list into multiple "channels"
> > makes more sense, where you default to one of them but can change it
> > via the preferences/unsubscribe administration. BTW: this is exactly
> > what happens for people wanting daily digests instead of individual
> > postings.
>
> That's an idea, but it means we have to patch mailman which will make
> future updates harder (unless mailman has provisions for such
> extensions). Maybe we convince them to integrate such a feature in the
> next release :)

It would make sense for it to support extensions like that. Just as you 
prefer inline patches on wine-patches, I'd like to see either inlined or 
attached patches on wine-cvs mail-outs rather than a URL. OTOH: I fully 
understand why the commit script's default action is to only send a URL, 
but as disk space and bandwidth are not (yet) a pressing concern for me 
I'd find it more convenient to just see the committed patch there. Again, 
I think the use of filters and value-adds like this is to give people 
what they want (and tolerate difference in what they send), rather than 
shackling them with the shared limitations of email, mailcap, and the 
consequent rules and regulations we use to get by amid the mess.

But if mailman can't do it, there would still be other ways to organise 
this, only they would be uglier and trickier. Do we actually know yet if 
someone at winehq will "let this happen"? And likewise, would Alexandre 
(as the primary target of wine-patches) like to express any thoughts on 
this? :-)

Cheers,
Geoff

-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/