Yes, a really detailed commit comment like that Linux one can work too, and I would be happy if I found that when doing code archaeology. But I guess I find that most of the time, a Jira ticket is a better place to hold that information. Somehow the developer is encouraged to write more, and it can also contain screenshots of the error, discussion with other developers, etc.
-- Stephen Turner -----Original Message----- From: Rene Moser [mailto:m...@renemoser.net] Sent: 18 May 2015 10:13 To: dev@cloudstack.apache.org Subject: Re: Preparing for 4.6 Hi Stephan On 18.05.2015 10:39, Stephen Turner wrote: > In my XenCenter dev team at Citrix, we have the policy of requiring a ticket > number on every commit. If we find a bug and there isn't already a ticket, we > create a ticket before committing the fix. I guess I've just dug through > history too many times to understand why something that appears wrong was > done, only to find an inadequate description at the end of the trail. IMHO understanding why commit x changed is more a problem of the commit message or description. If I pick a random fix commit in the linux kernel, https://github.com/torvalds/linux/commit/5c1ac56b51b9d222ab202dec1ac2f4215346129d you see this small fix and a detailed description, why. Personally I do not like the dependency to network related, centraliced ticket tracking system for understanding code changes of a distributed SCM. But I do see the advantage in seeing what has been reported to be broken and what commit fixes this bug. But the commit description should be fairly detailed, why a commit changed something. However since the changelog for the users is actually not generated from the git log, it makes totally sense to open a ticket before fixing bugs, to get all fixes covered in the changelog. Yours René
