patches policy

Shachar Shemesh wine-devel at
Mon Sep 9 23:55:51 CDT 2002

  I beg to differ.

When I copy/paste text, my mail compser feels it has the right (and for 
a good reason) to do stuff to the text. This may include changing tabs 
with spaces, word wraps, etc. These are exteremely annoying.

On the other hand, to the best of my knowledge, when I attach a text 
document, at least when I later view the message, the document is 
displayed inline (as opposed to actually being inline, which it isn't).

Dimitrie - please find one of my patch submissions, and let me know if 
it is displayed inline for you. If it is, attaching a file called .diff 
is the right way to go. If not, attaching .txt may be a solution. I am 
very much against copying the patch into the message, however.


Dimitrie O. Paun wrote:

>Hi all,
>There is something concerning submitting patches that bothers me
>to no end: inlining vs. attaching them.
>I don't know about others, but for me 99/1 rule applies: I at least
>skim over 99% of the patches inlines in the message, whereas
>I bother to read at most 1% of the ones attached/tar.gzed/ziped.
>Maybe I'm an extreme case, but there's got to be more to it than
>my personal quirks.
>If a patch is sent to wine-patches, it's sent there for peer review.
>If you don't want the review, send it to Alexandre directly, even
>though I suggest this is avoided as much as possible. However,
>it you do send it to wine-patches, please, *please* inline it!
>What about a nice patch submission policy:
>  -- unified diff only (required)
>  -- have a  decent subject (recommended)
>  -- a long description (optional, if the change warrants it)
>  -- a meaningful ChangeLog entry (required)
>  -- new files, if any, included in patch, diffed against /dev/null (required)
>  -- patch inlined at the end of the message (required)
>  -- one changeset per message
>Most of these things are already followed by most people, with the
>exception of the inlining bit. Alexandre, what about you reject patches
>that aren't in this format with a pointer to these rules? All this is a
>matter of habit, and I think we'll all benefit if these rules are followed.

More information about the wine-devel mailing list