[vlc-devel] [vlc-commits] vdpau: link against VDPAU_LIBS

[Ilkka Ollakka]

On Wed, Aug 07, 2013 at 10:10:37AM +0200, Rémi Denis-Courmont wrote:
> On Wed, 7 Aug 2013 10:41:04 +0300, Ilkka Ollakka <ileoo at videolan.org>
> wrote:

> His HLS plugin is not that old and it was complete crap. (For my own sake,
> I ignored it and let other people deal with the shit that one time. Guess
> what, they were not very happy about it.) His "enhancements" to the scene
> filter are also not that old.

I agree that HLS plugin has issues. According to git log he reverted the
scene changes on next day (same with transform), so I didn't count
those.

> Nothing works. The tone is irrelevant. He has failed to up his coding and
> pushing standards no matter how he was requested to do so.
> After all that time of mine and others that he has wasted, all the
> complaints voiced, all the cleanups after his mess, he well deserves to be
> qualified an idiot.

If the tone is irrelevant, is there really need to use such tone then?
Does it help you or someone else in anyway if it doesn't affect on
jpsamans habits?

> If he had bothered to read the damn source code instead of doing his
> typically stupid changes, if he had bothered to read the corresponding
> commit logs, and if he had used his brain, then he would not have committed
> this crap. That *is* the issue. And that is what makes him an idiot in my
> opinion.

The mentioning of runtime and libvdpau.so is in the first commit message
in modules/hw/vdpau/ directory. So yes, it seemed to be blind commit in
from jpsaman without checking more.

> His behaviour is unacceptable. The fact that he has carried it on for so
> many years is beyond outrageous. So of course I was outraged.

I agree that better aproach from jpsaman side would be to open trac
ticket if he had issue with the module. In a sense that you are actively
coding in that feature currently.

> (...)
> > Do you think this is the way to handle that kinda problems?

> Nothing solves the problem that I know of.

There is not likely that there would be any technical solution, but it
shouldn't stop us from searching means to resolve issues like we do now.
But just to be sure I understand the issue, you see the bug/code ratio
from jpsamans commits as the issue and that you feel that jpsaman
doesn't listen/hasn't listened your comments on his commits?

> Of course, retrospectively, we can say that you, TypX and No_Se (and
> consequently me) wasted a lot of time on the style of my mail. That of
> course makes it highly ineffective and counter-productive. But I do not
> take responsibility for your reactions.

And you shouldn't take responsibility on my reactions, they are mine to
have. Time is spend, but hopefully it's not all wasted.

Sure this takes my time away from coding vlc, but that doesn't really
lower my commit speed in any noticeable factor. And I want to try to
focus on resolving these non-technical issues too, as like you and
others have stated, we can't just let them be.

I'm actually happy about the course of these emails that we are writing
now and I think it shows that we as a people and vlc-devs are starting to
handle non-technical issues better than before. Not perfectly, but much
better than for example year or two ago?

> You should be spending time on the real issue of the Jean-Paul Saman abuse
> of the trust vested in him as a committer.

I don't think these issues are really that much separatable, and I felt
that the solution maybe would be easier to spot if approached from this
way.

I asked both of you in private email (you and jpsaman) on what would be
the wanted ending on your point of view. I don't mean that I expect that
either of you know the fix or howto proceed, just tried to jumpstart the
conversation about the problem.

-- 
Ilkka Ollakka
<Manoj> I *like* the chicken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20130807/c72ecb60/attachment.sig>