cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: Preparing for 4.6
Date Tue, 19 May 2015 07:51:07 GMT
Good points Erik, Mentioning a jira ticket is fine but as Wilder described
sometime superfluous. What you ask for here has a big +1 from me. What you
did can be seen in the commit diff, why you did it gives us a better view
of it's need over time and  in respect to the rest of the system.

thanks you,
Daan

Op di 19 mei 2015 om 08:33 schreef Erik Weber <terbolous@gmail.com>:

> 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