cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Weber <terbol...@gmail.com>
Subject Re: Preparing for 4.6
Date Tue, 19 May 2015 06:32:50 GMT
On Mon, May 18, 2015 at 1:14 PM, Daan Hoogland <daan.hoogland@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 <terbolous@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 <
> > WRodrigues@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.Turner@citrix.com
> > > <mailto:Stephen.Turner@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:WRodrigues@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.Turner@citrix.com
> > > <mailto:Stephen.Turner@citrix.com><mailto:Stephen.Turner@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:terbolous@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 <mail@renemoser.net
> <mailto:
> > > mail@renemoser.net><mailto:mail@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
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message