cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: Preparing for 4.6
Date Mon, 18 May 2015 11:29:56 GMT

> 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
View raw message