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:59:16 GMT
I must urge not to try to maintain a changelog by hand. it is error prone
and if people follow Erik's guideline of giving reason in a commit message
creating one from the git log becomes easy. It will be a matter of deleting
the irrelevant from the git log output.

Op di 19 mei 2015 om 09:53 schreef Rohit Yadav <rohit.yadav@shapeblue.com>:

> Hi,
>
> I think having JIRA references for bug tickets is useful for tracking
> fixes and should be encouraged, though for minor fixes it may be avoided.
>
> I also like the idea of maintaining the changelog every time a developer
> adds a new change instead of updating it at the time of release.
>
> I guess, without introducing a rule, we should encourage a guideline to
> encourage better commit messages, jira references, people updating
> changelog frequently and squashing large number of commits or merging as
> branch instead of fast forward merge.
>
> IMO I feel I’m seeing more important changes in recent months (such as
> more PRs, people waiting on Travis to go green, a lot of refactoring work
> and bugfixes) and don’t want to see anything applied that adds significant
> overhead in terms of developer/contributor/reviewer time.
>
> About PRs: In the past, I have had to do extra work to find the source
> repository and then add it as remote on my local git repo and then do the
> merge. So, if you’re a committer please push the branch on asf origin and
> send PR using that asf origin/branch which could make merging branches
> easier.
>
> Nowadays to speed up reviewing, once I’m done reviewing a PR I use a git
> alias to which I give the github pr link and it automatically commits the
> patch: https://github.com/bhaisaab/dotfiles/blob/master/git/gitconfig#L46
> (Usage: git pr :url).
>
> > On 18-May-2015, at 10:39 am, Sebastien Goasguen <runseb@gmail.com>
> wrote:
> >
> > I am also in favor of text changelog in the root.
> >
> > Creating JIRA for everything may lead to bad tickets anyway.
> >
> > What is also nice is a quick changelog. The habit would be for everyone
> to remember to update the change log when they do a commit (and agree on a
> format for it)...
> >
> >
> >
> >> On 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
> >>
> >
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>

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