[Mplayer-cvslog] CVS: main/libmpcodecs vd_xvid4.c,1.2,1.3

[Guillaume POIRIER]

Hi,
Le mar 05/10/2004 à 15:00, Diego Biurrun a écrit :
> Reimar Döffinger writes:
> > 
> > >>Renames xvid_ini to xvid_gbl_init and dec_p to xvid_dec_create
> > >>That'll make the move to 1.1.x front-end smoother.
> > > 
> > > WHAT THE HELL ARE YOU TALKING ABOUT????!!!
> > > 
> > > THIS COMMIT IS PURE COSMETIC, I DON"T SEE ANY FUNCTIONAL CHANGE.
> > > IT IS NOT POSSIBLE TO IMPROVE ANYTHING!!!
> > > 
> > > Revert immediately

How should I respond to an upper-case only email... Hum, it's not in my
temper to write back with the same aggressive tone.

Apparently, you're the maintainer of that piece of code. Diego told me
so, and that's also what I wrote on XviD mailling list...

I don't mean to offend you, but I'm curious how you may pretend to care
about anything that appends to that piece of core when you just ignore
the numerous mails that I sent to MPlayer mailling lists, and seem to
ignore the newly improved code that Edouard Gomez has made available
worldwide Sept, 1st.

Another thing that bugs me, is that nobody seem to care to explain me
why cosmetics change is a no-no, especially for a piece of code that
gets rarely updated, and on which no many people work. I do understand
that this is different for mplayer.c.
I'm, unfortunately, a very rational guy, so I really have problems
dealing with rules that don't make sense to me.
I'm not against rules, I just think it's unfortunate (this is an
understatement) when they prevent people from being productive.

I do agree that a cosmetic change such as a variable name change isn't
maybe worth it, but I also think it's really too bad that it's the only
thing that caught your attention, when I'd really have prefer not to
feel alone with the issue of moving to a 1.1.x-compatible front-end.

Yes, my goal is to have a front-end that is 1:1 equivalent to Edouard
Gomez, since he's the one who keeps it up to date against recent
development version of XviD.
Why do I want to do that?
First, because I trust Edouard judgment regarding producing good code,
as I really see no good reason why he'd screw the front-end in purpose.
Second, no one else, here in the dev team of MPlayer, _seems_ to
_really_ care about having a good support of XviD, that's the reason why
I tackled that issue. I started with documentation, and continue my work
with the front-end for the same reason: no one else is doing it.
Finally, as Reimar Döffinger said, I'm very humble regarding my
programming skills, so I don't want to modify it too deeply to mess it
up. I also don't want to loose too much time when Edouard will update
his front-end, figuring out where his changes should be made in out
"forked" front-end.
Of course, it would be great if Edouard could send directly his patches
against MPlayer front-end, but apparently, too many of his patches got
refused in the past, so he, very pragmatically don't send more patches
now. I don't blame him.


> > In his defense: he asked about that several times and got no reply 
> > except from me that I personally don't like it.
> > As I understood it he didn't want to modify the other patch too much as 
> > he doesn't understand it too well. And committing a patch that contains 
> > both cosmetics and code changes is even more unacceptable.

Yes, and I perfectly agree with that. I ran into the same issue when
working of XviD doc in MPlayer man page (with bot moving around
paragraphs and rephrasing some).


> > So tell him how to do it and I have the impression he will do it. I'm 
> > currently too confused by all these discussions that I can't give clear 
> > advice...

I really can't promise anything now. I throw lots of my time towards
proving decent patches to update the front-end in reasonable chunks at
once. The great amount of time it took me to work on those patches is
mainly due to my inexperience of collaborative development.
I'm not gonna have much available now that I'm back in school, to work
on this code the way Ivan likes it (provided that Ivan explains in
details what to do, and why doing so).
But if that's really necessary, because otherwise MPlayer would explode
in little pieces, I'd find some time to re-work my patches.
Right now, I'd really prefer to commit the second half of my patches
which I posted some days ago, that feature both real code and
documentation, and move on.


> Also in his defense: Ivan, you are not listed in the MAINTAINERS file
> as the XviD maintainer, so it is pretty hard to tell for a newcomer
> that XviD has a maintainer at all or that it could be you.

I must admit that you told me that Ivan has taken care of this in the
past. So the reason why I went down the road of sending patches myself
is just because in saw no reaction.
I'd happily welcome if someone would offer me to maintain XviD
front-end, which would consist, provided I become a maintainer, to work
ands in hands with Edouard, committing his patches after they'd have
been seen by enough people on the dev-eng list, forward bug reports to
him, if ever they are some.


> Guillaume is not subscribed to -cvslog.  Guillaume, this is something
> you have to do.  It's also written in cvs-howto.txt.  If you commit
> things you have to be available to fix your mistakes.

Now I'm subscribed to -cvslog. I wasn't previously as I thought it was a
read-only list that featured only messages from the cvs daemon.
I'm maybe playing with words, but so far, I wouldn't call what I've done
a "mistake", more a policy violation, even though I regret people take
it that way.
But should I pursue working on the front-end, I do agree that I'll
probably have to correct some 10l mistakes.

Anyway, thanks Reimar and Diego to plead in my favor, I really
appreciate it. I really want to help, and provide good help, but I also
what to understand.

Regards,
Guillaume
-- 
Avec la vérité, on va partout, même en prison.
        -+- Proverbe polonais -+-