[FFmpeg-cvslog] r14267 - trunk/libavcodec/ra288.c

[Vitor Sessak]

Uoti Urpala wrote:
> On Fri, 2008-07-18 at 13:30 +0200, Vitor Sessak wrote:
>> Uoti Urpala wrote:
>>> You can at most append the filenames, but that does not work well. If
>>> all commits were to a single file and every file was like "ra288.c"
>>> (which can be identified without path and has clearly defined
>>> functionality) then it would be mostly OK, but that is not the case for
>>> all commits and files, and so it's not a good system overall.
>> But do you agree it is to do by hand a task that could be automatized 
>> using just a list of modules and its respective files?
> 
> No. That does not work work for commits which touch several files or for
> files whose content boundaries do not match logical modules.
> 
> Nothing that is based on filename information alone can work. You need
> to understand the meaning of the commit to write the log message
> properly.
> 
> FFmpeg happens to have many "easy case" commits which change a single
> file with clearly limited functionality (specific to one codec/format).

Yes, and that is important. In FFmpeg, 99% of the commits either

1. Change only codecname.{c,h} (you'd put "codecname:" in the logs)
2. Change only Makefile/configure (you'd put "build:" in the logs)
3. You wouldn't add "module:" in the logs because it is not specific to 
any module (like fixing bugs in util.c)
4. Adding "module:" is redundant with the commit message (ex: "ARM: 
ARMv6 optimised bswap_16/32")

> But it's not the only case so you should consider how the system works
> in less trivial cases.

Why? Why do it always by hand when you need to do it only in the 1% 
corner cases? I'm favorable to adding "ra288:" to the log of a change in 
libavcodec/utils.c relevant only to ra288.

-Vitor

PS: those arguments wouldn't apply for a project less modular than ffmpeg...