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

[Reimar Döffinger]

Hi,
On Sun, Aug 21, 2005 at 02:20:04PM +0200, Attila Kinali wrote:
> +   A commit message should at least contain:

For some reason I thought the commit message should be short, if
possible one line... So that isn't possible then (making the log a bit
harder to read - I guess we should be careful not to overdo it).

> +   * A high level description of what the change does (fixes calculation of...).
> +   * A low level description, summary of the diff (int/int does not produce...).

Hmm... I don't really know what high and low level should mean in a more
general context. Maybe that should better be what it fixes and how?

> +   * A list of bug numbers, mailinglist archive links together with the
> +     Message-ID's of the mails of the bugs fixed
> +     (fixes bug #23, 
> +     http://www.mplayerhq.hu/pipermail/mplayer-users/2005-August/055157.html,
> +     Message-ID: <43084FB4.2090303 at poczta.onet.pl>).

Bugzilla entries okay, I usually add those, but message IDs is already
problematic (I have to find that mail, and sometimes I simply try to
fix a sample I downloaded half a year ago, how am I supposed to find the
mail?)
Pipermail URL is completely unacceptable, it takes ages to find the
correct URL and it also means I can't just go only for a short time to
commit but will have to start the browser etc.

> +   * A description of possible unwanted side effects (might not work in case X).

probably/know instead of possible? I mean, if I take the possible here
literally I can write a 1000+ words cvslog...

> +   * A summary of performed tests and benchmarks.

I'd like that more specific. What does "summary" mean? Something like
"tested on files X,Y,Z"? Also keep in mind that for testing the linux
-wid implementation for -vo gl I did > 20 tests, putting them all in the
cvslog doesn't really seem helpful to me - esp. since most of the
behaviour of -wid (e.g. in combination with -geometry) is not specified.

> +   * Severity of the bug/change.

I'm against that. Unless you specify a way of determining the severity.

> +   * One or more of the tags of:
> +       - cosmetic
> +       - crash-fix
> +       - rounding-fix
> +       - security-fix
> +       - spelling-fix
> +       - indention-fix
> +       - untested
> +       - new-feature
> +       - optimization
> +     marked with the keyword "TAGS:" in the first line of the commit message
> +     (eg "TAGS: new-feature, untested").

Hmm.. Probably a good idea, but I'm not sure if this should go in the
first or the last line. Also we will probably find out very soon that
(some of) the tags will not work as expected/are missing *g*

Greetings,
Reimar Döffinger