Hi there, I agree with the Jira ticket for the "new features, important fixes, security fixes"
But I don’t think only about "new features, important fixes, security fixes”. I put most of my time in make the code better and tested, for what we call refactoring/rewriting/redesigning. Should we also create Jira issues for that and mark them as Improvement? Taking into account the [VPC] Virtual Router, Citrix Resource Base and Libvirt Computing Resource refactoring, we had only internal issues on Jira. However, the changes have been documented on the 4.5/4.6 sections of the Apache / Developers / Design Documents wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin The Libvirt documentation is on its way, since the PR was pushed only last week. Cheers, Wilder On 18 May 2015, at 10:39, Stephen Turner <stephen.tur...@citrix.com<mailto:stephen.tur...@citrix.com>> 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. -- 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<mailto: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
