[MPlayer-cvslog] CVS: main configure, 1.1044, 1.1045 Makefile, 1.329, 1.330

[Rich Felker]

On Sun, Aug 21, 2005 at 10:26:08AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Aug 21, 2005 at 06:25:58AM +0200, Diego Biurrun wrote:
> > On Sat, Aug 20, 2005 at 09:30:04PM -0400, Rich Felker wrote:
> > > On Sat, Aug 20, 2005 at 06:46:36PM +0200, Diego Biurrun wrote:
> > > > 
> > > > BTW, can we all try to keep cvs log messages a bit more descriptive?
> > > > Things like 10l may be fun and quick to type and the problem may even be
> > > > obvious to those in the know, but don't forget that many people are
> > > > around to learn and explanations help them.
> > > 
> > > Are you talking about my v4l2 commit? IMO the error is obvious from
> > > the (one-line) patch. Dividing int/int to get a float does not work.
> > > Normally I say a lot more than just "10l" (or whatever amount) except
> > > when the error is obvious to anyone who knows C, or a typo, or a wrong
> > > numbers, etc.
> > 
> > Let's say that it was inspired by that commit, but I'm talking in
> > general, there are many more examples.  Yes, it will be obvious to those
> > in the know, but if you look at the output of 'cvs log' then 10l is not
> > descriptive unless you see the diff as well, while something like
> > "int/int does not produce a float value" is...
> 
> this is still not good, the commit log should at least contain
> * high level description of what the change does (fixing fps calculation
>   in setup_audio_buffer_sizes()) but actually thats still not good as it
>   says nothing about the conequences of the wrong fps ...

Actually I have no idea what the consequences were since I've never
used v4l2. However I expect it caused frame skipping or duplication at
the very least, and possibly broken a/v sync.

> * low level descrioption / diff summary like (int/int does not produce...)

IMO when the diff is short someone can be expected to read it..

> * list of bug numbers / mailing list archive links which get fixed

In my case none. I just discovered it by reading someone's v4l2 output
on -users.

> * possible unwanted sideeffects of the change
> * summary of any test/benchmarks done

Agree these should be included when relevant.

> * severity of the bug/change

This is the cola amount. :)

> * some list of tags from (cosmetic/crash-fix/rounding-fix/security-fix/
>   spelling-fix/indention-fix/untested/new-feature/optimization)

rounding-fix is not a good name for something like this. It's more
like major-incorrect-behavior.

Anyway I agree with lots of your motivations here, but I don't think
it'll happen anytime soon..
:)

Rich