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

[Michael Niedermayer]

Hi

On Sun, Aug 21, 2005 at 03:00:13PM +0300, Ivan Kalvachev wrote:
> 2005/8/21, Michael Niedermayer <michaelni at gmx.at>:
[...]
> > 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 ...
> > * low level descrioption / diff summary like (int/int does not produce...)
> > * list of bug numbers / mailing list archive links which get fixed
> > * possible unwanted sideeffects of the change
> > * summary of any test/benchmarks done
> > * severity of the bug/change
> > * some list of tags from (cosmetic/crash-fix/rounding-fix/security-fix/
> >   spelling-fix/indention-fix/untested/new-feature/optimization)
> 
> Somehow I cannot imagine that You Michael will write an cvs explanation
> 6 times bigger than the patch itself ;) 
> After all you are the master of 10^x,l cola explanations ;)
> 
> Anyway seriously, the text should say what it fix, the bug number etc..
> 
> Severity is a litlle overkill,and benchmarks too except when the
> change is in time critical section (e.g. inside codec loop), even then
> it should say faster/slower and probable %.
> If there are sideeffects then the fix is bad.

sometimes sideeffects are unavoidable (mess vs ABI breakage for example)


> This applies to the done test too, I mean it is developer jobs to test
> the commit and finds it OK, 

the developer might not have the hardware to test something


[...]
> 
> It is also not good idea to mark security-fix, as there are noobies
> that cann't find them without these tags :)

IMO, the noobies who cant find them without the tags cant exploit them so 
this is not an issue, but the overworked binary package maintainers of some
distros would probably benefit from them

[...]
-- 
Michael