> On May 18, 2015, at 1:14 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > > I don't like the writing of a changelog in the root, it is in git already.
Even in a release tarball ? > The comments should be good and describing the changes. The changes should > be small enough to be described adequately in a short changelog. That's why > I don't like squashing anything but the very trivial. > > Op ma 18 mei 2015 om 11:50 schreef Erik Weber <terbol...@gmail.com>: > >> On a related note, commits should reference the JIRA ticket as well. >> >> -- >> Erik >> >> On Mon, May 18, 2015 at 11:27 AM, Wilder Rodrigues < >> wrodrig...@schubergphilis.com> wrote: >> >>> 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 >>> >>> >>
