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

[Michael Niedermayer]

On Fri, Jul 18, 2008 at 04:49:45PM +0300, Uoti Urpala wrote:
> On Fri, 2008-07-18 at 15:13 +0200, Vitor Sessak wrote:
> > Uoti Urpala wrote:
> > > 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")
> 
> Not close to 99%. 

And what is the value? You dont know? then why do you pretend you do?


> And even for those cases there is no automatic
> solution that would actually work well now.

No? how did you exhaustively or by proof confirm there is no solution?
You didnt? then why pretend you do?


> 
> > > 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.
> 
> What you seem to be missing is that a human must check and approve the
> result. 

must? we didnt so far and universe.so didnt die with division by 0 so i
assume we do not have to.


> If you just write a commit message like "simplify" then it is
> not possible for the computer to tell whether 1) you consider
> automatically filling in the default context information guessed from
> the changed file "libavcodec/ra288.c" to be appropriate
> or 2) context
> information is already present in a form the computer doesn't easily
> recognize or is completely missing but cannot be easily guessed from the
> file list. Cases where the computer can't fill in the most appropriate
> context are more common than 1%.

The computer cannot tell with certainity ever what the user truely
wants, still its rather easy to decide on a standarized format 
for modules and let the computer fill things in if there is no match.
grep '^[a-zA-Z0-9]*:' is the obvious solution after spending 2sec on it.

As a sideeffect that would also work quite well with the existing messages
while existing messages would not be compatible with "the kernel way"


> 
> If you want to create a script to start your editor with "ra288:"
> already filled in when you start writing a commit message feel free to
> do so. 

> But trying to automatically fill it in later with no human check
> of the result doesn't work well.

No? Could you mail me your paper with the proofs and extensive tests,
i seem to be unable to find it on citeseer.

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080718/89c614aa/attachment.pgp>