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 Mon, 18 May 2015 11:14:30 GMT
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.

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