Hi, I think having JIRA references for bug tickets is useful for tracking fixes and should be encouraged, though for minor fixes it may be avoided.
I also like the idea of maintaining the changelog every time a developer adds a new change instead of updating it at the time of release. I guess, without introducing a rule, we should encourage a guideline to encourage better commit messages, jira references, people updating changelog frequently and squashing large number of commits or merging as branch instead of fast forward merge. IMO I feel I’m seeing more important changes in recent months (such as more PRs, people waiting on Travis to go green, a lot of refactoring work and bugfixes) and don’t want to see anything applied that adds significant overhead in terms of developer/contributor/reviewer time. About PRs: In the past, I have had to do extra work to find the source repository and then add it as remote on my local git repo and then do the merge. So, if you’re a committer please push the branch on asf origin and send PR using that asf origin/branch which could make merging branches easier. Nowadays to speed up reviewing, once I’m done reviewing a PR I use a git alias to which I give the github pr link and it automatically commits the patch: https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig#L46 (Usage: git pr :url). > On 18-May-2015, at 10:39 am, Sebastien Goasguen <run...@gmail.com> wrote: > > I am also in favor of text changelog in the root. > > Creating JIRA for everything may lead to bad tickets anyway. > > What is also nice is a quick changelog. The habit would be for everyone to > remember to update the change log when they do a commit (and agree on a > format for it)... > > > >> On 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 >> > Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
