cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Turner <>
Subject RE: Preparing for 4.6
Date Mon, 18 May 2015 09:38:34 GMT
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,

Stephen Turner

-----Original Message-----
From: Rene Moser [] 
Sent: 18 May 2015 10:13
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,
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.


View raw message