[vlc-devel] [PATCH] Make cached module configuration on 64 bits work again

[Rafaël Carré]

Le 25/01/2013 11:40, Rémi Denis-Courmont a écrit :
> Le vendredi 25 janvier 2013 12:13:53, Rafaël Carré a écrit :
>> Le 25/01/2013 10:33, Rémi Denis-Courmont a écrit :
>>> Le vendredi 25 janvier 2013 05:37:18, Rafaël Carré a écrit :
>>>> So I ask you apologize for this totally undeserved comment.
>>>
>>> After the thankless hours I spent cleaning up module_t and partly
>>> module_config_t, this is ABSOLUTELY OUTRAGEOUS.
>>
>> Thankless hours do not give you the right to insult the work made by
>> other people.
> 
> The comment is totally deserved. The way that the Qt4 plugin extracts 
> configuration from the core is crap. It is not as bad and buggy as it used to 
> be, thanks to many hours of work by me and pretty much only me.

I didn't really follow your work on this specific code but I trust you
when you say that it used to be worse.

I was under the impression that you had written helpers to avoid doing
that (you mentioned "LibVLC functions")

> And instead of encouraging me and thanking me to go forward with the rework, 
> you ask me to apologize. Who the hell do you think you are?

Sorry but if you talked about it a bit more I would be more likely to
encourage and thank you. Most of the time I have no idea what you are
doing exactly.
(I admit I don't read 100% of the commits landing on git)

>>> But you seem to be again on a trip to piss me off since the last few
>>> days.
>>
>> I just wish you would look back at yourself and see that you are very
>> liberal in your emails.
> 
> That's so hypocritical. You question my technical decisions, just because they 
> inconvenience you or your work (e.g. LibVLC interface breakage).

Let me correct you straight:
I *do* question your technical decisions but not on technical points, I
do this because I have lot of trouble decoding your speak and I believe
this is a point you could enhance.

To this day I still have no idea what is the issue (about LibVLC
interface breakage), and I have asked other developers for advice.
To my understanding you did not give any hint on what is incorrect.

Also I did not follow up on the last time that patch was submitted
because back then the tone between the two of us was very harsh.

As told already I am very thankful to you that this time is now behind
us so I didn't want to reply to the old messages.

I am definitely accepting that you are maintaining large piece of codes
and understand them better than I do, and thus I accept your decisions.

Also I am dedicated to improve patches until you think there are right I
am sending several patches on the list when I could commit them straight
away without asking for your opinion.

But when you say "patch rejected", "wrong", "I said it already in some
unspecified mail in an unidentified thread at some point in the past",
that leaves little or no room for improvement on my side.
I honestly don't know what to do at this point for this specific patch
even after asking several people for pointers.

The real inconvenience is the lack of a foreseeable path for progress.

> You blame my 
> code for being undocumented, while it's actually specified but you cannot be 
> bothered to read the specification (e.g. atomic operations).

How many devs you think have read the full C legalese-speak
specification? There *are* other ways to learn about this stuff and you
know it. I have learned about many parts of the C language without
looking at this horribly boring document.

> And then you blame 
> the code for being confusing but fail to propose how it could be less so...

>> I don't record anyone on this list use the term "fucking" when talking
>> about your work for a start, so the least you could do is returning the
>> same favor to others.
> 
> fucked-up, adjective:
> - Damaged or poorly manufactured.
> - Annoying, evil or wrong. 
> 
> I did not use the term fucking either. 

You're right. "fucked-up" indeed doesn't have the same meaning than
"fucking", so IMO the fact that I interpreted it in a more offensive way
should point that "fuck*" words should be avoided when possible, below
you give a list of synonyms which IMO are more suited for our communication.

> And even if I had written "crap" or 
> "poorly written", "bug-prone" or "very ugly", it would just be as vexating to 
> an hypothetical person attached to that code. I am not going to stop 
> criticizing the code base just to avoid hypothetically hurting people's ego.

You're also right that someone could still be vexated whatever words are
used. So please use some care to not make it more vexating than it needs be.

> Otherwise, we can forget about the whole code review thing.
> 
> For the record, I think the people that *designed* the affected code have all 
> left the project for many years. So much for their emotional attachment...

I wrongly took your message for an attack on current devs who worked on
Qt4, sorry for that.

Still.. when you take the time to write an e-mail I wish you also take
the time to be a bit more explicit and not use words lightly. That would
be greatly appreciated.

This would help avoiding misunderstandings.

On my side I assume that what you do is for improving the project, but I
often have trouble understanding what you mean, can you do something
about that on your side?

Thanks,