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 08:15:28 GMT
That is called a commit message. It could be a joke but I am serious. The
first exerpt-like line should read exactly what you are describing.

On Tue, 19 May 2015 10:08 Sebastien Goasguen <runseb@gmail.com> wrote:

>
> > On May 19, 2015, at 9:59 AM, Daan Hoogland <daan.hoogland@gmail.com>
> wrote:
> >
> > I must urge not to try to maintain a changelog by hand.
>
>
> I should not have used the term  changelog.
>
> I am used to do this in libcloud:
>
> https://github.com/apache/libcloud/blob/trunk/CHANGES.rst
>
> it’s just a good habit. You make a commit, you write a line in the file,
> with a pointer to the PR or the JIRA bug and a short description.
>
> It saves having to struggle for changes at release time (jira filters seem
> to break etc and not everything gets to JIRA…as we are discussing)
>
> So I am not asking for an overly complex process, I am just saying:
>
> -when you commit something, you write a one line in a text file with a ref
> to somewhere -
>
>
>
> -seb
>
> > 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