Re: [Evolution] Improve commit messages in Git repository

[Milan Crha <mcrha redhat com>]

On Tue, 2012-09-11 at 12:42 +0200, Paul Menzel wrote:
> > Regarding the explanation in the commit, I like the bug numbers being
> > clickable,
>
> Milan, unfortunately that is not the case. Neither yet in the Web
> interface nor will it ever be the case when using `git` on the command
> line.

        Hi,
it's clickable here:
http://git.gnome.org/browse/evolution-data-server/commit/?id=efc20ad0

> > thus one can see whole story about the change, rather than
> > summarizing it to few sentences. I agree that bug reports can be sometimes long
> > and hard to read, but it's still the place where the change can be discussed.
>
> Please look at it from the perspective of package maintainers. They are
> (like you) already overloaded by work and have to keep up with dozens of
> packages. You cannot expect them to know all the code bases and
> understand all patches and to find out the implications.
>
> Additionally please do not expect people to look at every commit and
> then at every discussion in Bugzilla. The commit message is the place to
> describe the problem with its implications, how it was introduced and
> how it is fixed and what implications the fix has.
>
> It would be awesome, if that policy for commits could be set up. (This
> issue was discussed somewhere already, but again I cannot find the
> report in GNOME Bugzilla or the message in the list archive. Matthew
> acknowledge the problem and promised to improve that if I remember
> correctly. :/)

There might be no bugs, nor regressions, knowing all the above :)

The reason is that I'm not going to spend double time on writing commit
comments, especially if the commit is dedicated to the bug report, where
I usually try to explain the cause of the issue and what the patch
fixes, if it looks non-obvious.

I agree with the per-patch issue, and I very rarely apply patches to
packages on my own, the most for test packages or when some sever issue
is found and the release date is too far away. The correct thing is to
follow upstream releases, rather than apply patches on respective
packages. At least from my point of view.
        Bye,
        Milan