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

[D J Hawkey Jr]

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.

   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.

   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
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?

---

These comments are just my own; the developers have made it clear that they
do not agree. So be it; it's their software, it's their choice. But such
rules have likely let a lot of good patches go by due to violation of these
rules? I have and do maintain several software packages, as well as submit
patches to many other packages, so I believe I do know from where I speak.
But again, it's the developers' choice.

I understand that the developers are trying to weed out the good stuff from
the noise. But that's part of the task of maintaining a project; if they
can't "keep up" with the volume, they can always just go as fast as they
want to. They don't have to, nor shouldn't, IMO, make it a distasteful or
burdensome process for somebody else who's only trying to make the software
a little better.

Note that I am not subscribed, so please don't carry this thread any further.
It's rather off-topic to the list, and at least one of the developers would
just as soon see me drop dead anyway.

Dave

-- 
  ______________________                         ______________________
  \__________________   \    D. J. HAWKEY JR.   /   __________________/
     \________________/\     hawkeyd at visi.com    /\________________/
                      http://www.visi.com/~hawkeyd/