anks!
Mike
From: Will Stevens
Sent: Friday, May 20, 2016 5:30 PM
To: dev@cloudstack.apache.org
Subject: Re: Variable renaming in classes meant for Agents
Unless that PR was not already accounted for in a grandfathered exception.
On May 20, 2016 7:26
, May 20, 2016 5:30 PM
To: dev@cloudstack.apache.org
Subject: Re: Variable renaming in classes meant for Agents
Unless that PR was not already accounted for in a grandfathered exception.
On May 20, 2016 7:26 PM, "Daan Hoogland" wrote:
> In the mutiny PR I had to change the names that I
gt;
> > > *CloudOps* *| *Cloud Solutions Experts
> > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > > w cloudops.com *|* tw @CloudOps_
> > >
> > > On Fri, May 20, 2016 at 12:49 PM, Tutkowski, Mike <
> > > mike.tutkow...@netapp.com
&
gt; > Also, does this mean that we have zero Hyper-V integration tests run
> > > during CI?
> > >
> > > From: Tutkowski, Mike
> > > Sent: Friday, May 20, 2016 10:47 AM
> > > To: dev@cloudstack.apache.org
> &g
> > ____
> > From: Tutkowski, Mike
> > Sent: Friday, May 20, 2016 10:47 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Variable renaming in classes meant for Agents
> >
> > Yeah, it has to go into 4.9. :) Unless n
ing CI?
> >
> > From: Tutkowski, Mike
> > Sent: Friday, May 20, 2016 10:47 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Variable renaming in classes meant for Agents
> >
> > Yeah, it has to go into 4.9. :)
utkowski, Mike
> Sent: Friday, May 20, 2016 10:47 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Variable renaming in classes meant for Agents
>
> Yeah, it has to go into 4.9. :) Unless no one cares about Hyper-V.
>
> From: Rafael Weingär
harden it up.
> > >
> > > I'm going to open a PR and revert the names in those changed "Command"
> > > files for 4.9. That will solve the immediate problem.
> > >
> > > From: Rafael Weing
blem here, though, is that this particular piece of code is
> > super fragile, so it would be great to harden it up.
> >
> > I'm going to open a PR and revert the names in those changed "Command"
> > files for 4.9. That will solve the immediate problem.
> >
Yeah, it has to go into 4.9. :) Unless no one cares about Hyper-V.
From: Rafael Weingärtner
Sent: Friday, May 20, 2016 10:42 AM
To: dev@cloudstack.apache.org
Subject: Re: Variable renaming in classes meant for Agents
You are right Mike about the “_”. The
, Mike
wrote:
> Yeah, I'm just teasing. :) The PR needs to go into 4.9 to fix Hyper-V.
>
> From: Rafael Weingärtner
> Sent: Friday, May 20, 2016 10:49 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Variable renaming in classes meant
Yeah, I'm just teasing. :) The PR needs to go into 4.9 to fix Hyper-V.
From: Rafael Weingärtner
Sent: Friday, May 20, 2016 10:49 AM
To: dev@cloudstack.apache.org
Subject: Re: Variable renaming in classes meant for Agents
I think that if we say we su
Also, does this mean that we have zero Hyper-V integration tests run during CI?
From: Tutkowski, Mike
Sent: Friday, May 20, 2016 10:47 AM
To: dev@cloudstack.apache.org
Subject: Re: Variable renaming in classes meant for Agents
Yeah, it has to go into 4.9
20, 2016 10:42 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Variable renaming in classes meant for Agents
>
> You are right Mike about the “_”. The point is that in some other language
> the use of “_” makes sense, whereas in Java it does not, at least not the
> way it has
lem.
>
> From: Rafael Weingärtner
> Sent: Friday, May 20, 2016 9:12 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Variable renaming in classes meant for Agents
>
> Hi guys,
> I agree with Daan that if class fields have improper (not
ck.apache.org
Subject: Re: Variable renaming in classes meant for Agents
Hi guys,
I agree with Daan that if class fields have improper (not descriptive or
not suitable) names we should change them. However, I do not find the
change (on variable names) introduced by PR #816 good. It added an
“_”(und
Hahaha, do not get addicted to it Daan ;)
That is probably due to the environment I am living in right now. I am not
a member per se of the GsonLD project [2]; I have just used it in another
research/work.
So, there is this protocol called OpenID Connect, and one of the things we
did not like muc
Rafael [2] is a members only link (pornographia academia?)
On Fri, May 20, 2016 at 5:12 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:
> Hi guys,
> I agree with Daan that if class fields have improper (not descriptive or
> not suitable) names we should change them. However, I do not
It might be a total pipe dream, but if the API was also Swagger compliant,
it would simplify our API documentation and would make API tooling much
easier. I have not looked into what would be required, but it would
definitely be a nice to have. :)
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cl
Hi guys,
I agree with Daan that if class fields have improper (not descriptive or
not suitable) names we should change them. However, I do not find the
change (on variable names) introduced by PR #816 good. It added an
“_”(underline) before variable names; even though Apache CloudStack has a
lot of
Guys, we should rename fields that have improper names. I do not agreee
with the statement at all. Your two solutions to the serialisation hazard
are both acceptable to me. leaving a non compliant or non explanatory name
in because it slipped through the nets at some points does not seem
acceptable
Thanks for sending out this e-mail, Anshul.
This is a bit of a strange situation because we need to make sure people are
either aware of the fact that properties in Command classes are serialized (and
not change existing variable names) or come up with a less fragile way of
choosing property na
22 matches
Mail list logo
