cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Turner <Stephen.Tur...@citrix.com>
Subject RE: Preparing for 4.6
Date Mon, 18 May 2015 09:16:08 GMT
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
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>>
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>>
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
View raw message