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 08:39:27 GMT
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.

Stephen Turner

-----Original Message-----
From: Erik Weber [] 
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6

On Mon, May 18, 2015 at 10:26 AM, Rene Moser <> wrote:

> Hi
> On 15.05.2015 11:27, Sebastien Goasguen wrote:
> > Folks,
> >
> > As we prepare to try a new process for 4.6 release it would be nice 
> > to
> start paying attention to master.
> >
> > - Good commit messages
> The question is, what makes a commit message good? Maybe this helps:
> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> PDqu2ZkGk1a/
> > - Reference to a JIRA bug
> Must there be a JIRA bug? I did some commits without jira bugs in the 
> past. But I noticed that those are not "tracked" in the changelog of 
> the new release. So should there be a policy (is there?) that there 
> must be a jira bug for fixes?
I believe there should be a JIRA bug for most things. JIRA is a good place to document why
you're doing something, it's also easy to use as a source for release notes as you discovered.
It's also good practice to document bugs/fixes, it's generally easier to find JIRA bugs than
it is to find commit messages - especially for non-developers / newbies.

For major code commits (new features, important fixes, security fixes) I'd say it should be
a requirement, but I don't know if it already is or not.

> > - Squashing commits ( cc/ wilder :))
> This really depends. I would not generally prefer squashing commits.
> The example of
> is more an 
> example of "bad" commit messages.
> If you look at the commits, they make sense but the commit message 
> indicates that they cover similar work in different aspects, which 
> they actually don't.
> But if you look at this example here
> =gregdek where you can see dozens of similar commits, those should be 
> squashed.

+1 to squashing related commits where it makes sense to do so
-1 to a general rule of squashing the whole PR

View raw message