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

[Reimar Döffinger]

Hello,
On Wed, Mar 21, 2007 at 12:05:13PM +0100, Guillaume Poirier wrote:
> diego wrote:
> > Author: diego
> > Date: Wed Mar 21 11:48:10 2007
> > New Revision: 8465
> > 
> > Modified:
> >    trunk/libavformat/utils.c
> > 
> > Log:
> > av_estimate_timings_from_pts() flushes the packet queue but doesn't
> > reset the streams' cur_dts values.  This can lead to a fatal "error,
> > non monotone timestamps ..." message later, because the out-of-date
> > cur_dts values are used to compute some packet's dts.
> > 
> > Fix this by calling av_read_frame_flush() and eliminate code
> > duplication in the process.
> > 
> > The additional hunk gives more detailed error messages.
> > 
> > patch by Wolfram Gloger, wmglo dent.med.uni-muenchen de
> 
> Would anyone have an objection to systematically add a reference to
> the thread where the committed patch was posted?
> 
> I always do it under "original thread" and give the mail subject and
> date. Very few people do it currently, which is too bad IMHO.
> 
> I find it quite handy to immedialty find the discussions there were
> about the patch, which can sometimes help understanding the patch.
> 
> Other than the fact that it slows down a bit patch committing, I'd
> like to hear any objection about making it a policy rule when applying
> non-trivial patches.

It makes the log messages longer and harder to skim through when
searching for something. In this case the log message is quite long
anyway though. Another disadvantage is that you can access the
information only when you either have email archive or web browser at
hand, whereas the log information for those of use using git or similar
is even available when there is no internet at all.
But most importantly I think sometimes log messages and email thread
references are misused for things that should actually be documented in
the code.
So in short: there are cases where adding such a thread reference
makes sense, but in most cases IMO it is not necessary (no real
discussion about the patch) or misplaced (documentation should be in the
code, not in an email thread) or the essence of the discussion can be
captured in a two-line log message.

Greetings,
Reimar D?ffinger