[Ffmpeg-devel] Re: [Ffmpeg-cvslog] r8465 - trunk/libavformat/utils.c

[Reimar Döffinger]

Hello,
On Wed, Mar 21, 2007 at 05:46:35PM +0200, Uoti Urpala wrote:
[...]
> I also think length isn't that important even if it takes
> more than two lines.

Just to explain why length of log messages seems important at all to me:
1) svn log output is just horrible to read, long log messages make it
even worse, esp. as it defaults to giving all info and there is no
simple way to make it say print the 10 messages before and after the given
revision for that specified line. If someone knows some magic to make
svn log more useful I'm interested...
2) grep has a much higher probability of false positives if there is
much more text, esp. since grep makes it a bit hard to "refine" searches
(though it is of course possible).

And I just don't think the stupid-approach of making it policy to always
add it is such a good idea, there are quite a few threads that consist
of the original mail with one line that ends up in the log and a "looks
ok" in another mail ;-).
I would be more for making this a policy suggestion, something like
"if you think you can't explain the essence of the patch and possibly the
discussion that lead to it in a few lines, consider referencing the
mailing list thread". Developers can then complain when such a reference
is missing and they would have found it appropriate. If we come to see
clear cases where it makes always sense to include it that can be made
part of the real policy.

> > Many patches are being discussed longer than one reply, thread is very
> > useful when you need to understand/remember why it was done that way.
> > 
> > By experience, I thought many times "thanks Guillaume for mentioning
> > thread reference".

I haven't had that experience except maybe once, so it is hard for me to
fully understand/appreciate. That's why I am somewhat more for the
"nudging" approach, hopefully helping everyone getting more of an idea
what is best in a log message. Of course it will probably take more time
and effort getting a result out of this approach.

> 8461:
> =====
> treat frame_size > 1 as compressed audio
> =====
> 
> This requires at least checking which file(s) the commit changes to make
> much sense, and still doesn't tell what kind of practical effect this
> change might have. I think it would be better to mention "mov/mp4 muxer"
> in the commit message itself and possibly mention which practical case
> this improves/fixes.

The problem here is that including the file name adds redundant
information, which feels stupid to me, and also complicates the logs
when reading only the log for a single file. It also is not as good as
an automated solution, since at least I end up writing the file name
sometimes with path, without path, with extension or without or not
writing the filename at all but something like "mov/mp4 muxer" which is
suboptimal for a grep search.
IMO this is really a huge shortcoming of svn log (not including the
affected file names) and should be "fixed" there somehow.

Greetings,
Reimar D?ffinger