[MPlayer-dev-eng] Quick fix to new input method

[D Richard Felker III]

On Sun, Sep 08, 2002 at 07:38:28PM -0500, D J Hawkey Jr wrote:
> On the 8th, Diego Biurrun wrote:
> >
> >> I don't care if I'm not following your patch-submission protocol; either
> >> you'll fix this problem or you won't. IMO, your protocol is unreasonable.
> > 
> > What exactly is so unreasonable about it?
> 
> Numbers 1, 4, and 7 of the DOCS/tech/patches:
> 
>    1. Always make patches for the CVS version.
>       We do not accept patches for old versions or releases.
> 
> Developers ought to take patches made against the latest release, not just
> CVS. It _is_ the released code, and I believe this rule places more burden
> onto the individual submitting the patch than what the developers ought to
> carry. The developer decides if a patch is irrelevant, not those who submit
> patches.

No. It is not the developers' job to cater to you. If you have a
feature you want included, then you should take the trouble to make an
acceptable patch that applies cleanly to latest cvs. Don't expect
someone else to try to figure your mess out when patch bombs with
rejects.

>    4. Read your patch. We'll *refuse* it if it changes indentation of the
>       code or if it does tab/space conversion or other cosmetical changes!
> 
> There are at least four different "code styles" in the source tree; just
> which "style" ought to be adhered to? Even in any one source module, many
> "styles" can be found. If the patch is readable and reasonable, accept it;
> the developers can format it to whatever they like with whatever tools they
> use.

Use whatever style you like, but DO NOT CHANGE STYLE/INDENTION OF
EXISTING CODE. It's not that hard. Personally I require a common style
in the projects I maintain, but this is the rule for MPlayer, and if
you want to code here, you deal with it.

>    7. Subscribe to the mplayer-dev-eng list (don't worry, it's low traffic)
>       and send your patch there as base64-encoded attachment (use gzip or
>       bzip2 *only* if it's really big or if you know that your mailer messes
>       up (reformats) text attachments).
> 
> In many instances, I think an "inline" inclusion of a patch should be just

No, inline patches will often get tabs/spaces messed up by mailers,
and then they don't apply cleanly.

> fine, if it's small, and easily readable. And subscribing to the list should
> not be a requirement; it's more of a convenience, don'tcha think?

Subscribing is (almost) necessary if you want to discuss the patch
after it initially gets rejected for being broken, as in your case.
Otherwise it's hard to keep the threading, and list members will
overflow their idegs if you keep sending a new message and breaking
threading everytime you reply!

Anyway, if you took the time to learn about the project and the way
development works before stepping in and loudly and rudely expressing
your opinions, maybe you would have gotten farther. The rules in
patches.txt are pretty much 100% non-negotiable. Arguing about them
here will only get people mad, since we've heard the same arguments
100 times before.


Rich