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

[Michael Niedermayer]

On Fri, Jul 18, 2008 at 07:13:11PM +0300, Uoti Urpala wrote:
[...]
> 
> > > 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. 

"acceptable" by what standards? by yours?
The extra module names are usefull in some cases and useless and clutter
screen space in others.

Besides, i welcome that human that can create such "acceptable" messages for
more than just a subset of the messages. It does not seem we have any of
that kind around currently.
So as manual adding the module names wont be perfect, i really dont see
what kind of argument it is to say that the script wont work with all
messages ...


> However making it work with all the various frontends
> through which commit messages can be seen would be a big practical
> problem

If you want to fix all bugs (not limited to the display of modules) in all
frontends, feel free to do so. Failing that, the inability of one or
more frontends to deal with something is of no relevance to me.
We also wont split files in less than 100byte each if theres a buggy
frontend around that segfaults otherwise. What matters are the tools
actually used by the ffmpeg developers.

Besides, how many frontends have the ability to remove module names
when they are redundant and just clutter screen space? Are you going
to fix them all before adding module names to your commit messages?


> so adding the context explicitly to all new messages would still
> be preferable. 

preferable by you, but you are not a ffmpeg developer. I think mans
is the only one that is really in favor of this and is a ffmpeg developer.
I dont remember if diego just complained about the general low quality
of commit messages or if he also wanted module: prefixes.


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

theres various information like the commiter name, revission number, date
number of lines changed ...
combining these in a vissually clean way is the job of the frontend, an
additional word for the module is not particularly hard to add in there.
(as can be seen by my script)

Having it hardcoded in and not logically seperated from the commit message
is more limiting, as it has to be removed and this only works if a strict
format is followed by the developers.


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

Well you make claims as if everything was fact. While really you are just
guessing wildly and leaning toward what best fits your current agenda.
The english language has words for expressing ones lack of certainity and
knowledge.


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

First, we only have one developer that wants the module names, thus we
do not have a very strong need to have any system, automatic or otherwise
that adds these module names.
That of course is seperate of the general low quality of commit messages
which really is a seprate problem.

Second, commit messages and other things should be done so that most
developers are happy about how its done. Again we clearly have more
people (reimar, vitor, me ...) that see no need to add module names
brute force by hand everywhere. 

Third, I did post a one line script, showing how to add the filenames
cleanly to the svn log output.
You are welcome to write your own if the output displeases you. Or if you
want information different from the file names that isnt in the commit
message already. And again id like to say that our commit messages are
often bad, and that for example a commit to utils.c that just affects ra288
should mention this in the commit message.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- 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/b18e3f14/attachment.pgp>