Okay, +1 for create the ACS Jira issue for improvements as well.
Since Xen and Libvirt redesign will be on 4.6 - and are already documented - I will just create 2 issues so we have a way of keeping track of them. Cheers, Wilder On 18 May 2015, at 11:16, Stephen Turner <stephen.tur...@citrix.com<mailto:stephen.tur...@citrix.com>> wrote: Speaking for my XenCenter team again, for things like that we would have an improvement ticket, pointing to the wiki page. By the way, this also allows us to schedule the work on our sprint, but we had the policy even before we were doing Scrum. In a large, distributed, volunteer organisation, I would argue that it's even more important to be able to trace the change back to its reason, now and later. -- Stephen Turner -----Original Message----- From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com] Sent: 18 May 2015 10:11 To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> Subject: Re: Preparing for 4.6 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><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><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
