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

[Uoti Urpala]

On Fri, 2008-07-18 at 16:38 +0200, Michael Niedermayer wrote:
> 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?

I didn't bother calculating the exact percentage (IMO the exact value
doesn't matter much and it obviously varies over time). I did enough
checking to see that 99% was quite exaggerated.

I clearly did not pretend to have calculated the exact value. If you
have no sensible arguments and can't even come up with better insults
then don't post at all.

> > 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?

I didn't mean theoretical existence but that there is currently no
automatic solution that would work well even for a subset of commits.

> > 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"

You could create a script that would create acceptable messages for some
subset of commits. However making it work with all the various frontends
through which commit messages can be seen would be a big practical
problem so adding the context explicitly to all new messages would still
be preferable. There are also some smaller problems like text layout (if
you can't see how much space the automatic information part used when
writing the message).

> > 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.

This is again such a stupid "argument" that I wonder why you posted it
at all. Obviously nobody has written anything with "proofs and extensive
tests" (and a strict "proof" of something being impractical would be
hard in general).

Do you have some rational objection to what I said? Like an example of a
project where such an automatic system works well? If something is
practical then demonstrating it should be much easier than showing no
previously untested way could possibly work for something thought to be
impractical.