This is something we can call nitpiking or low priority.
I would like we introduce 3 new hacking rules to enforce the cohesion
and consistency in the base code.
Using boolean assertions
Some tests are written with equality assertions to validate boolean
conditions which
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 t
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
re these new rules makes
sense on other openstack projects.
Jordan
- Original Message -
From: "Sahid Orentino Ferdjaoui"
To: "OpenStack Development Mailing List (not for usage questions)"
Sent: Friday, November 21, 2014 5:57:14 PM
Subject: Re: [openstack-dev] [nova]
On Fri, Nov 21, 2014 at 8:57 AM, Sahid Orentino Ferdjaoui <
sahid.ferdja...@redhat.com> wrote:
> 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 cal
les to the hacking project here
> : https://github.com/openstack-dev/hacking ? I am sure these new rules makes
> sense on other openstack projects.
>
> Jordan
>
> - Original Message -
> From: "Sahid Orentino Ferdjaoui"
> To: "OpenStack Developme
On Fri, Nov 21, 2014 at 10:30:59AM -0800, Joe Gordon wrote:
> On Fri, Nov 21, 2014 at 8:57 AM, Sahid Orentino Ferdjaoui <
> sahid.ferdja...@redhat.com> wrote:
>
> > 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 <
> > > s
On 11/21/2014 01:52 PM, 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
On Fri, Nov 21, 2014 at 04:15:07PM -0500, Sean Dague wrote:
> On 11/21/2014 01:52 PM, 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 wha
Whoops, that should say "assertions" not "exceptions".
- Original Message -
> From: "Solly Ross"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Monday, November 24, 2014 12:00:44 AM
> Subject
elopment Mailing List (not for usage questions)"
>
> Sent: Friday, November 21, 2014 5:23:28 PM
> Subject: Re: [openstack-dev] [nova] Proposal new hacking rules
>
> On Fri, Nov 21, 2014 at 04:15:07PM -0500, Sean Dague wrote:
> > On 11/21/2014 01:52 PM, Matthew Treinish wro
cepted by Nova community first before to think about other
projects ;)
> > Jordan
> >
> > - Original Message -
> > From: "Sahid Orentino Ferdjaoui"
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >
>
On Fri, Nov 21, 2014 at 05:23:28PM -0500, Matthew Treinish wrote:
> On Fri, Nov 21, 2014 at 04:15:07PM -0500, Sean Dague wrote:
> > On 11/21/2014 01:52 PM, Matthew Treinish wrote:
> > > On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:
> > >> Hey,
> > >> I am not a Nova developer but
On Fri, Nov 21, 2014 at 10:30:59AM -0800, Joe Gordon wrote:
> On Fri, Nov 21, 2014 at 8:57 AM, Sahid Orentino Ferdjaoui <
> sahid.ferdja...@redhat.com> wrote:
>
> > 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 <
> > > s
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2/ expected/actual - incorrect failure messages have cost me more time
than I should admit to. I don't see any reason not to try to
Matthew Gilliard said on Mon, Nov 24, 2014 at 02:50:08PM +:
> 1/ assertFalse() vs assertEqual(x, False) - these are semantically
> different because of python's notion of truthiness, so I don't think
> we ought to make this a rule.
> 2/ expected/actual - I don't see any reason not to try to imp
On 11/24/2014 08:50 AM, Matthew Gilliard wrote:
> 1/ assertFalse() vs assertEqual(x, False) - these are semantically
> different because of python's notion of truthiness, so I don't think
> we ought to make this a rule.
>
> 2/ expected/actual - incorrect failure messages have cost me more time
> t
On 11/24/2014 09:40 AM, Ben Nemec wrote:
On 11/24/2014 08:50 AM, Matthew Gilliard wrote:
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2/ expected/actual - incorrect failure m
On 11/24/2014 01:02 PM, pcrews wrote:
On 11/24/2014 09:40 AM, Ben Nemec wrote:
On 11/24/2014 08:50 AM, Matthew Gilliard wrote:
1/ assertFalse() vs assertEqual(x, False) - these are semantically
different because of python's notion of truthiness, so I don't think
we ought to make this a rule.
2
On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
> I think pointing out that the default failure
> message for testtools.TestCase.assertEqual() uses the terms
> "reference"
> (expected) and "actual" is a reason why reviewers *should* ask patch
> submitters to use (expected, actual) ordering.
On 11/26/2014 06:20 AM, Nicolas Trangez wrote:
On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
I think pointing out that the default failure
message for testtools.TestCase.assertEqual() uses the terms
"reference"
(expected) and "actual" is a reason why reviewers *should* ask patch
submitters
On Wed, 2014-11-26 at 08:54 -0500, Jay Pipes wrote:
> On 11/26/2014 06:20 AM, Nicolas Trangez wrote:
> > On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
> >> I think pointing out that the default failure
> >> message for testtools.TestCase.assertEqual() uses the terms
> >> "reference"
> >> (exp
On Wed, Nov 26, 2014 at 08:54:35AM -0500, Jay Pipes wrote:
> It's not about an equality condition.
>
> It's about the message that is produced by testtools.TestCase.assertEqual(),
> and the helpfulness of that message when the order of the arguments is
> reversed.
>
> This is especially true with
On 11/26/2014 09:28 AM, Nicolas Trangez wrote:
On Wed, 2014-11-26 at 08:54 -0500, Jay Pipes wrote:
On 11/26/2014 06:20 AM, Nicolas Trangez wrote:
On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
I think pointing out that the default failure
message for testtools.TestCase.assertEqual() uses
On 11/26/2014 07:54 AM, Jay Pipes wrote:
> On 11/26/2014 06:20 AM, Nicolas Trangez wrote:
>> On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
>>> I think pointing out that the default failure
>>> message for testtools.TestCase.assertEqual() uses the terms
>>> "reference"
>>> (expected) and "actu
On 26/11/14 09:33, Louis Taylor wrote:
On Wed, Nov 26, 2014 at 08:54:35AM -0500, Jay Pipes wrote:
It's not about an equality condition.
It's about the message that is produced by testtools.TestCase.assertEqual(),
and the helpfulness of that message when the order of the arguments is
reversed.
26 matches
Mail list logo
