[MPlayer-cvslog] CVS: main/libmpcodecs ve_x264.c,1.33,1.34

[Diego Biurrun]

I'm coming back to this after more than a day to have the situation cool
off a bit.  Ivan, let's try to keep the flames low, please.

On Mon, Aug 22, 2005 at 02:45:47AM +0300, Ivan Kalvachev wrote:
> 2005/8/22, Diego Biurrun <diego at biurrun.de>:
> > On Mon, Aug 22, 2005 at 01:33:41AM +0300, Ivan Kalvachev wrote:
> > > 2005/8/21, Diego Biurrun <diego at biurrun.de>:
> > > >
> > > > I have no idea what it does and how and I really cannot be bothered to
> > > > find out because I have very little time at the moment.  Besides, our
> > > > CVS policy is clear, see DOCS/tech/cvs-howto.txt:
> > > >
> > > > 11. Update the documentation if you change behavior or add features. If
> > > >     you are unsure how best to do this, send a patch to mplayer-docs,
> > > >     the documentation maintainers will review and commit your stuff.
> > >
> > > Of course, You wrote it, haven't you?
> > 
> > I wrote it, but what I wrote down is what was agreed to on dev-eng.  Why
> > haven't you objected before if you don't like the rules?  It's been
> > there for almost a year...
> 
> And it is quite common that developers didn't read docs, this file of
> course is routed to docs maillist not the cvs one.

You are mistaken, DOCS/tech is routed to mplayer-cvslog.  It was routed
to mplayer-docs only for a short time but then moved back to -cvslog for
the very reason that not all devs read -docs.  Here's proof:

http://www.mplayerhq.hu/cgi-bin/cvsweb.cgi/CVSROOT/loginfo
http://mplayerhq.hu/pipermail/mplayer-cvslog/2004-September/019508.html

And as I said, all of this was discussed on dev-eng before it was added
to the policy.  You may have missed it when it passed over -cvslog or
-dev-eng, maybe it was during the period where you had trouble with your
mail provider.

> Yep, you are quite smart. I was the one that first proposed
> documentation maillist and developers to send notes to maintiners. It
> wasn't approved back then, but it came to reallaty later.
> Unfortunately I didn't expect that you will force developer to write
> the manual instead of you. Very smart.

I cannot force anyone to write the manual "instead of me" since it is
not my duty to write it in the first place.  I very much dislike the way
you speak about "job" during all of this thread.  We're all here for the
fun of it, nobody gets paid to do it and I never signed a contract that
forces me to write all the documentation.  I never even said I would
write all the documentation for the project nor will I in the future, at
least not without inhaling some crack first.

Yes, I am the documentation maintainer and yes, I'm even the main
committer to the documentation.  I consider my function as maintainer to
review documentation patches and keep the documentation in good shape.
This includes asking other devs to document what they have done.  When
they have provided a rough outline I take that and go from there, fixing
bugs, making it (hopefully) easier to understand and keeping it
consistent with the rest of the docs.  It's a win-win situation.  Devs
know what the code does and are good (and quick) at providing an
outline, I'm good (and quick) at fleshing docs out.

Nevertheless I cannot write all the documentation by myself, there are
parts that I just don't understand well enough.  It's normal, MPlayer
is too big for one person to know completely and many parts depend on
certain kinds of hardware, like graphics or sound boards, TV cards or
many other things.  It's impossible for me to keep up with all the other
developers, I just don't have the time, nobody has.  Thus everybody
has to help me out or the documentation will not get written at all
or be incomplete and bad.  That's it, pure and simple.  So far I have
not heard many complaints about the way I maintain the documentation.
On the contrary, feedback is overwhelmingly positive.  Even when I nudge
people to document what they have committed, nobody ever told me to stop
it.  Don't forget that there are far less people taking care of
documentation than of code and writing docs takes time, too.

> Actually I am pissed of from you sending back and back quite good
> patches because of minor manual issues. 

I call that reviewing patches and it includes asking for updates and new
revisions.  I also help patch senders with the documentation.  But no good
patch has been kept out of CVS because of missing or bad documentation.
Patch senders just provide updates or I fix it up myself.  On the
contrary, there are many patches where I reviewed the docs part but
nobody else bothered reviewing the code part and they are now rotting in
/dev/null.  Show me a patch where this happened or retract this
accusation.

> > > don't loose more time and just do your job. And your jobs is not
> > > hunting developers to write manuals.
> > 
> > Don't tell me what my job is.  You are being rude and insolent, quit the
> > flaming now, it is completely uncalled for.
> 
> You need two for flaming, I haven't started this one.
> 
> And it comes to show that you prefer to flame me, instead of doing it
> by yourself.

I cannot do it with reasonable effort as I have said before.  I have no
experience with MEncoder and I don't even have x264 installed.  Getting
to the point where I have an environment to test this and RTFSing enough
to understand what the code does might take me between two hours and a
day.  Is it unreasonable to ask you for 5-15 minutes of your time then?

In between exchanging flame mails with you I managed to commit about 5
times, btw...

Now Ivan, could you PLEASE invest those 5-15 minutes of your time to add
something like 3-5 lines to the man page?  I'm really not asking for
much here.  It should take you very little effort.

Diego