[FFmpeg-cvslog] r14267 - trunk/libavcodec/ra288.c

[Uoti Urpala]

On Sun, 2008-07-20 at 01:38 +0200, Michael Niedermayer wrote:
> On Sat, Jul 19, 2008 at 11:12:29PM +0300, Uoti Urpala wrote:
> > On Fri, 2008-07-18 at 22:20 +0200, Michael Niedermayer wrote:
> > > On Fri, Jul 18, 2008 at 07:13:11PM +0300, Uoti Urpala wrote:
> > > > > As a sideeffect that would also work quite well with the existing messages
> > > > > while existing messages would not be compatible with "the kernel way"
> > > > 
> > > > You could create a script that would create acceptable messages for some
> > > > subset of commits. 
> > > 
> > > "acceptable" by what standards? by yours?
> > 
> > Any script is likely to either miss needed information or add
> > significant clutter to some messages.
> 
> So you suggest that we add the clutter by hand to every single message ...

You can normally add the information without clutter by hand. Scripts
won't be able to do it equally well and will either miss required
information or add clutter.

> > information. Your script didn't do a particularly good job in even the
> > simple cases. It produced for example
> > M format/rtpdec.c  M format/rtpenc.c
> > That already takes so much space that it's hard to meaningfully describe
> > the commit on one line.
> > The "RTP: " in the original gave enough information about the changed
> > files.
> 
> Well, to me "M format/rtpdec.c  M format/rtpenc.c" is a lot more usefull
> than "RTP:"
> The first tells me that the commit did change both and the author did not
> forget one of them. The second does not.

And the full patch would be much more "useful" still in that sense. But
the relevant goal here is not getting the maximum amount of information
but picking the most relevant/interesting commits as quickly as possible
or quickly getting an overview of what kind of things changed in a large
group of commits. 

>  And i honestly do not care if the
> messages take 1 or 2 lines. I rather like to have all information which _I_
> need there.

Of course it's normal for the log messages of nontrivial commits to take
a paragraph or a few. But you don't want to read paragraphs of text per
every commit before getting any idea what the commit is about if you're
looking at a large group of them. So the first line should already give
some rough idea of the contents, with increasingly specific details
following later if necessary.

> People who do not want the file list dont have to view it, svn supports
> both variants and i suspect git as well.

But viewing the logs without a file list requires the messages to make
sense without knowing the files, and viewing the logs with a file list
is suboptimal for many uses because the list adds a lot more clutter and
reading time than well written context information in the log message
would.

> > > > > > If you want to create a script to start your editor with "ra288:"
> > > > > > already filled in when you start writing a commit message feel free to
> > > > > > do so. 
> > > > > 
> > > > > > But trying to automatically fill it in later with no human check
> > > > > > of the result doesn't work well.
> > > > > 
> > > > > No? Could you mail me your paper with the proofs and extensive tests,
> > > > > i seem to be unable to find it on citeseer.
> > > > 
> > > > This is again such a stupid "argument" that I wonder why you posted it
> > > > at all. Obviously nobody has written anything with "proofs and extensive
> > > > tests" (and a strict "proof" of something being impractical would be
> > > > hard in general).
> > > 
> > > Well you make claims as if everything was fact. While really you are just
> > > guessing wildly and leaning toward what best fits your current agenda.
> > > The english language has words for expressing ones lack of certainity and
> > > knowledge.
> > 
> > I don't feel a need to express uncertainty when I say that adding
> > missing information to log messages with your own custom scripts is not
> > a practical solution.
> 
> Your claim was not at all limited to any scripts, neither custom ones and
> least, ones written by me.

I said it was about automatically filling in the information (in
practice with a program). I see no reason why you'd consider calling
that a "script" to be a significant limitation. 

Yes the part you quote doesn't talk about the additional fact that any
such automation would need custom changes for FFmpeg which could easily
make it impractical to use even if you somehow created an algorithm that
would generate the wanted information. I wrote that from the viewpoint
of the overall thread; but I stand by the claim that you're unlikely to
generate good results even without considering integration into
practical workflow.

I did not mean "using your own custom scripts" as in you personally but
as in "representing yourself in court".

> > > Third, I did post a one line script, showing how to add the filenames
> > > cleanly to the svn log output.
> > 
> > Which didn't give a particularly good result.
> 
> Thank you for your personal (and always trollish) oppinion.
> The output of the script is frankly alot more usefull to me than what
> has been proposed, that is no files and some human written module prefixes.

Useful for what purpose? Enough context information to make sense of the
message can usually be added in a couple of words, which is unlikely to
take away room from anything more important. The details of the file
list take more room and are usually not the most important thing you'd
want to know about the commit first.

> Now please understand that the ffmpeg project will continue to format its
> commit messages as the majority of its developers likes best and which is
> most usefull to us. Iam sorry if that displeases you, or even if it makes
> your head explode with a division by zero due to it contradicting your
> equality axiom of "personal oppinion" == "ultimate truth".

So you again attempt to write insults. This time you try to portray me
as overly confident in my own opinions ... and do so in the form of a
deduction which implicitly assumes that if you do things a certain way
in FFmpeg then nobody can fail to believe it is the ultimate truth.

Nice one.