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

[D J Hawkey Jr]

On the 8th, at around 2100, D Richard Felker III wrote:
> 
>> 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.

Those are the rules, yes. I wasn't asking to be catered to, I handed them
a fix to their stuff. Maybe not even an appropriate fix, but a fix, and
an easy one, at that. The "mess" you write of is a one-line change.

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

Ah. My misunderstanding. I thought it meant that the patches themselves
should adhere to the "style" found, so that it "fits in".

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

For large and/or "complex" patches, yes, I agree. I wrote of small patches,
as mine was. Even OE wouldn't mangle that patch so badly that it wouldn't
apply cleanly. I'm certain patches aren't applied blind; a developer would
have at least looked a small patch over, as he read the mail, right? He
could then ditch it if he wanted to, as opposed to a hard-and-fast rule.

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

No argument. I didn't anticipate any feedback as a result of my mailing,
let alone the two I've had.

As to my patch being rejected, fine. If the developers don't care to
fix something with a patch from nowhere (read: "freebie" or "gift")
because it failed their guidelines, that's their business, not mine.

As to my patch being broken, yes, the first was. I then sent a retraction,
with an even smaller patch that's correct. Did you even look at either
of them? You know that body of code so well you knew my second patch was
broken the moment you laid eyes on it? Pfft. The released code is broken,
as was the code in CVS five minutes before I submitted the patch. It
still is, as a matter of fact.

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

You don't have to preach to me, I've been here before. Nor do you have
to proclaim me "loud" and "rude"; I was more than fair in writing that
my opinions are clearly my own, and not agreeable to the developers. I
was polite, and didn't use caps, exclamation points, or other markup
tags. Where did you see "loud" and "rude"?

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

I WAS ASKED WHAT I THOUGHT WAS UNREASONABLE, RIGHT HERE IN THIS D*MNED
LIST, SO I ANSWERED, YA JERK!

There. That's loud and rude. See the difference?

I'm outta here. MPlayer is nice, but can work even better. The group
around it isn't, and likely can't.

Dave

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