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:44:50 GMT
the release tarball is a repo snapshot. do you want a generated changelog?

Op ma 18 mei 2015 om 13:30 schreef Sebastien Goasguen <runseb@gmail.com>:

>
> > On 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.
>
> Even in a release tarball ?
>
> > 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