On Fri, Nov 21, 2014 at 01:52:50PM -0500, Matthew Treinish wrote:
> On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:
> > Hey,
> > I am not a Nova developer but I still have an opinion.
> > 
> > >Using boolean assertions
> > I like what you propose. We should use and enforce the assert* that best 
> > matches the intention. It's about semantic and the more precise we are, the 
> > better.
> > 
> > >Using same order of arguments in equality assertions
> > Why not. But I don't know how we can write a Hacking rule for this. So you 
> > may fix all the occurrences for this now, but it might get back in the 
> > future.

Let write this rules in HACKING.rst, developers and reviewers are
expected to read it.

> Ok I'll bite, besides the enforceability issue which you pointed out, it just
> doesn't make any sense, you're asserting 2 things are equal: (A == B) == (B 
> == A)
> and I honestly feel that it goes beyond nitpicking because of that. 
> 
> It's also a fallacy that there will always be an observed value and an
> expected value. For example:
> 
>   self.assertEqual(method_a(), method_b())
> 
> Which one is observed and which one is expected? I think this proposal is just
> reading into the parameter names a bit too much.

Let developer to know about what values was expected when he broke a
test during his development without looking into the testcase code.

Operators can also want to know about what values was
expected/observed without reading the code when executing tests.

> > 
> > >Using LOG.warn instead of LOG.warning
> > I am -1 on this. The part that comes after LOG. (LOG.warning, LOG.error, 
> > LOG.debug, etc) is the log level, it's not a verb. In syslog, the 
> > well-known log level is "warning" so the correct method to use here is, 
> > imo, log.warning().

Well I have choiced 'warn' because there is less changes but I do not
have any preference, just want something clear from Nova.

> > Have you concidered submitting this hacking rules to the hacking project 
> > here : https://github.com/openstack-dev/hacking ? I am sure these new rules 
> > makes sense on other openstack projects.

Make them accepted by Nova community first before to think about other
projects ;)

> > Jordan  
> > 
> > ----- Original Message -----
> > From: "Sahid Orentino Ferdjaoui" <sahid.ferdja...@redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)" 
> > <openstack-dev@lists.openstack.org>
> > Sent: Friday, November 21, 2014 5:57:14 PM
> > Subject: Re: [openstack-dev] [nova] Proposal new hacking rules
> > 
> > On Thu, Nov 20, 2014 at 02:00:11PM -0800, Joe Gordon wrote:
> > > On Thu, Nov 20, 2014 at 9:49 AM, Sahid Orentino Ferdjaoui <
> > > sahid.ferdja...@redhat.com> wrote:
> > > 
> > > > This is something we can call nitpiking or low priority.
> > > >
> > > 
> > > This all seems like nitpicking for very little value. I think there are
> > > better things we can be focusing on instead of thinking of new ways to nit
> > > pick. So I am -1 on all of these.
> > 
> > Yes as written this is low priority but something necessary for a
> > project like Nova it is.
> > 
> > Considered that I feel sad to take your time. Can I suggest you to
> > take no notice of this and let's others developers working on Nova too
> > do this job ?
> > 
> 



> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to