On Mon, 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. > 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. > IMHO, the ChangeLog, Commit message or JIRA Issue we rely on should say /why/ something is done. Typically git commit messages often say /what/ has been done. Here's a recent example (I don't mean to bash that particular commit, it's just one of the latest commits I found): https://github.com/apache/cloudstack/commit/9d8a62d0ee379bf8b67405944c86f68587245db6 It states that a package was added, but not why. That makes it hard in the future to say if it is still needed or not. A ChangeLog or JIRA issue related to the same commit could say why it had to be done, coupled with an error message or similar. Luckily, the majority of commits mention a JIRA issue. -- Erik > > 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 > > > > > > > > >
