cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Turner <Stephen.Tur...@citrix.com>
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 [mailto:terbolous@gmail.com] 
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 <mail@renemoser.net> 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:
>
> http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2
> d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid
> QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh
> PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F
>
> > - 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
> https://github.com/apache/cloudstack/commits/master?page=2 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
>
> https://github.com/ansible/ansible-modules-extras/commits/devel?author
> =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

--
Erik
Mime
View raw message