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

Geoff Thorpe geoff at geoffthorpe.net
Fri Oct 10 11:16:17 CDT 2003


FWIW: I'm away soon for a few days, so you'll have to continue this 
without me (a fact which is no doubt to your infinite relief :-).

On October 10, 2003 11:27 am, Dimitrie O. Paun wrote:
> On Fri, 10 Oct 2003, Geoff Thorpe wrote:
[snip]
> I haven't dispatched you to the archives to be rude, but to avoid
> rehashing the same arguments over and over again. Saving time is
> important, at least in my books, as I have a chronic lack of it :) My
> point is that most of the people here, in particular Alexandre, prefers
> inlined patches for many reasons, some of which I've outlined already.

Sure, I understand that.

> I really don't understand why we have this entire argument in the first
> place. One thing that is certain is that one wine-patches we would like
> *ideally* to receive patches inlined. As you say, the point of having
> such a filter is to accomodate as many different "styles" of
> submission, and we do that by translating all those style (if possible)
> to the prefered style, and that one is inlined.

I would correct that to "and we do that by translating all those styles 
(if possible) to a prefered style, and that one is what each reader finds 
easiest to use."

It's perfectly clear that some people with certain mail setups prefer 
inlined, and some prefer attached. Any argument with that? 
Insignificantly perhaps, I prefer attachments because they are decidedly 
easier for me to use; I can file-browse into my CVS repository, 
drag-n-drop the diff, and get a multi-panelled color dialog showing me 
the before-and-after picture. I can't do that with the original email 
itself, nor can I browse the diff itself with syntax highlighting without 
first manually extracting the patch from the email. If only one 
list-server output is possible, inlined patches will be the norm. If more 
than one is possible, wine-patches will be a better service for more 
people. Feel free to disagree with that logic, but it seems pretty clear 
to me. BTW: if delivery of wine-patches to your own address generated 
inlined patches anyway, would you object on any non-philosophical grounds 
to *submitting* your patches as attachments anyway? You are expressing a 
preference after all for how you prefer to receive patches, so would you 
similarly accommodate other people's tastes if it made no difference to 
you? No matter what you're receiving/processing list mail with, I think 
sending with attachments is universally pretty easy, and as I say it is 
very difficult to extract patches from an email except by passing the raw 
mail data directly through 'patch', which you may not want or be able to 
do in some setups.

> So we have two orthogonal things here:
>   1. Should we have such a filter?
>   2. Should we dissus the prefered style?

s/preferred/default/

> I don't think I'd like to reopen the n-th time the discussion about
> (2), but if you feel you have good arguments...

Only that there are indisputably situations where attachments are easier 
and more flexible to use, though they happen not to be your situation nor 
Alexandre's (using your current setups). The question is; is wine-patches 
a service *to* as many people as possible, or is it a sevice for a couple 
of core developers *from* as many people as possible? That's not 
rhetorical, I think it's an open question.

Open source increasingly dissolves the traditional roles of developers and 
users and, as far as wine is concerned, I am one of these new byproducts: 
a "participant". Do I help wine or does wine help me? The answer: neither 
and both. My preferences count, but to who? and how?

> BTW, the purpuse of wine-patches is twofold:
>   1. For Alexandre to apply a patch. He has spoken before, and he
>      prefers inlined patches; (please read the section on style
>      http://www.winehq.org/site/docs/wine-devel/style-notes )

I think we're agreed that one of the major roles of such a filter would be 
to produce more consistent output, and being able to consistently inline 
patches would clearly be one of the most valuable features for people 
like yourself and Alexandre. No argument here.

>   2. For others to review patches, and again, inlined patches
>      are better.

For some, this is indeed true. But could I have them as attachments 
please? :-)

> The case of multiple patch submission is a red herring. In the 7 years
> I've been with the project, I haven't seen a single case of someone
> submitting alternate patches. Yes, there were people submitting
> mutliple (separate) patches as one email, but this is strongly
> discouraged, as I've already said. And even if that happens, just
> letting them be would nicely take care of things.

Reality check: dereferencing a NULL pointer is "strongly discouraged", 
receiving multiple patches in an email is "marginally annoying and should 
have a damned good reason". C'mon, this is open source, *nix, and the 
uber-world - when did we all suddently turn into puritans and forget that 
we can be flexible precisely because we control our systems and tools and 
have a choice of what we use and how we prefer to operate? Concrete rules 
and "don't touch" inflexibility, that sounds a lot like Microsoft.

Cheers,
Geoff

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




More information about the wine-devel mailing list