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:terbol...@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 <m...@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
