Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
MIME-Version: 1.0
References: <C4781760-BA54-4DD2-832B-D729C008A3B1@gmail.com>
 <5559A21F.6020103@renemoser.net>
 <CAP997Ud+dDa29EoLD1H7BHLD4e60VTbAQw6C9S+8ueCS+zxtBA@mail.gmail.com>
 <85B56B1AEDD2674A82DEC8B61E12182925994FEF@AMSPEX01CL01.citrite.net>
 <D3680DBC-753D-4315-BEB0-5053B5D1AFCB@schubergphilis.com>
 <85B56B1AEDD2674A82DEC8B61E1218292599506E@AMSPEX01CL01.citrite.net>
 <7DBAEC08-5F0B-4938-9469-59638DABA534@schubergphilis.com>
 <CAP997UcDg_n3qUssV153K48n+YXYTiM415rKseXSoK=YmwC4xw@mail.gmail.com>
In-Reply-To: 
 <CAP997UcDg_n3qUssV153K48n+YXYTiM415rKseXSoK=YmwC4xw@mail.gmail.com>
From: Daan Hoogland <daan.hoogland@gmail.com>
Date: Mon, 18 May 2015 11:14:30 +0000
Message-ID: 
 <CAGQtxvZXihuJBrcChsTq4EnPWcLDQ32+tAwd4+pAmZeeU2YJWA@mail.gmail.com>
Subject: Re: Preparing for 4.6
To: dev <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=089e0158c1665a39990516594c46

--089e0158c1665a39990516594c46
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't like the writing of a changelog in the root, it is in git already.
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 hav=
e
> > 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=E2=80=99t think only about "new features, important fixes, se=
curity
> > fixes=E2=80=9D. I put most of my time in make the code better and teste=
d, 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+Redun=
dant+Virtual+Router+Implementation
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenSer=
ver+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 th=
e
> > 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 th=
e
> > 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 sour=
ce
> > for release notes as you discovered.
> > It's also good practice to document bugs/fixes, it's generally easier t=
o
> > 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 no=
t.
> >
> >
> >
> > - 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=3D2 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
> > =3Dgregdek 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
> >
> >
>

--089e0158c1665a39990516594c46--