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

[Michael Niedermayer]

Hi

On Wed, Mar 21, 2007 at 02:00:48PM +0100, Reimar D?ffinger wrote:
> 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.

what about:
if a disscussion about some change happened before the change was commited
then the subject and data of that thread should be provided in the commit
message

?


also i surely agree that things should be documented in the code
instead of mail threads but if they are documented in mail threads instead
of the code i think its better if we "link" to the thread ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070321/5b216c2b/attachment.pgp>