For anyone who's interested, the final removals are in a series starting
here: https://review.openstack.org/#/c/142585/
On 12/09/2014 05:39 AM, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on p
On 12/16/2014 06:22 PM, Ben Nemec wrote:
> Some thoughts inline. I'll go ahead and push a change to remove the
> things everyone seems to agree on.
>
> On 12/09/2014 09:05 AM, Sean Dague wrote:
>> On 12/09/2014 09:11 AM, Doug Hellmann wrote:
>>>
>>> On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
On Tue, Dec 16, 2014 at 3:22 PM, Ben Nemec wrote:
> Some thoughts inline. I'll go ahead and push a change to remove the
> things everyone seems to agree on.
>
> On 12/09/2014 09:05 AM, Sean Dague wrote:
> > On 12/09/2014 09:11 AM, Doug Hellmann wrote:
> >>
> >> On Dec 9, 2014, at 6:39 AM, Sean D
Some thoughts inline. I'll go ahead and push a change to remove the
things everyone seems to agree on.
On 12/09/2014 09:05 AM, Sean Dague wrote:
> On 12/09/2014 09:11 AM, Doug Hellmann wrote:
>>
>> On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
>>
>>> I'd like to propose that for hacking 1.0 we d
On Tue, 2014-12-09 at 13:46 -0500, Sean Dague wrote:
> Yes, the following fails H305 and H306.
>
> nova/tests/fixtures.py
>
> """Fixtures for Nova tests."""
> from __future__ import absolute_import
>
> import gettext
> import logging
> import os
> import uuid
>
> import fixtures
> from oslo.con
On 12/09/2014 02:46 PM, Jeremy Stanley wrote:
> On 2014-12-09 13:49:00 -0500 (-0500), Sean Dague wrote:
> [...]
>> And I also think that if a commit message change doesn't retrigger all
>> the tests, people will be a lot happier updating them.
>
> Agreed--though this will need a newer Gerrit plus
On 2014-12-09 13:49:00 -0500 (-0500), Sean Dague wrote:
[...]
> And I also think that if a commit message change doesn't retrigger all
> the tests, people will be a lot happier updating them.
Agreed--though this will need a newer Gerrit plus a new feature in
Zuul so it recognizes the difference in
On 12/09/2014 12:07 PM, Jeremy Stanley wrote:
> On 2014-12-09 11:56:54 -0500 (-0500), Sean Dague wrote:
>> Honestly, any hard rejection ends up problematic. For instance, it
>> means it's impossible to include actual urls in commit messages to
>> reference things without a url shortener much of the
On 12/09/2014 12:20 PM, Kevin L. Mitchell wrote:
> On Tue, 2014-12-09 at 12:05 -0500, Sean Dague wrote:
>>> I agree that dropping H302 and the grouping checks makes sense. I
>> think
>>> we should keep the H301, H303, H304, and the basic ordering checks,
>>> however; it doesn't seem to me that the
On Dec 9, 2014, at 10:05 AM, Sean Dague wrote:
> On 12/09/2014 09:11 AM, Doug Hellmann wrote:
>>
>> On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
>>
>>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>>
>>> 1 - the entire H8* group. This doesn't function on pyt
On Tue, 2014-12-09 at 12:05 -0500, Sean Dague wrote:
> > I agree that dropping H302 and the grouping checks makes sense. I
> think
> > we should keep the H301, H303, H304, and the basic ordering checks,
> > however; it doesn't seem to me that these would be that difficult to
> > implement or maint
On 2014-12-09 11:56:54 -0500 (-0500), Sean Dague wrote:
> Honestly, any hard rejection ends up problematic. For instance, it
> means it's impossible to include actual urls in commit messages to
> reference things without a url shortener much of the time.
Fair enough. I think this makes it a human
On 12/09/2014 11:58 AM, Kevin L. Mitchell wrote:
> On Tue, 2014-12-09 at 10:05 -0500, Sean Dague wrote:
>> Sure, the H8* group is git commit messages. It's checking for line
>> length in the commit message.
>
> I agree the H8* group should be dropped. It would be appropriate to
> create a new gat
On Tue, 2014-12-09 at 10:05 -0500, Sean Dague wrote:
> Sure, the H8* group is git commit messages. It's checking for line
> length in the commit message.
I agree the H8* group should be dropped. It would be appropriate to
create a new gate check job that validated that, but it should not be
part
On 12/09/2014 11:28 AM, Jeremy Stanley wrote:
> On 2014-12-09 07:29:31 -0800 (-0800), Monty Taylor wrote:
>> I DO like something warning about commit subject length ... but maybe
>> that should be a git-review function or something.
> [...]
>
> How about a hook in Gerrit to refuse commits based on
On 12/09/2014 11:41 AM, Johannes Erdfelt wrote:
> On Tue, Dec 09, 2014, Sean Dague wrote:
>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>
>> 1 - the entire H8* group. This doesn't function on python code, it
>> functions on git commit message, which makes it toug
On Tue, Dec 09, 2014, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason to prev
On Tue, Dec 09, 2014 at 10:15:34AM -0600, Brian Curtin wrote:
> On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote:
> > - [H305 H306 H307] Organize your imports according to the `Import order
> > template`_ and `Real-world Import Order Examples`_ below.
> >
> > I think these remain reasonable guid
On Tue, Dec 09, 2014, Sean Dague wrote:
> This check should run on any version of python and give the same
> results. It does not, because it queries python to know what's in stdlib
> vs. not.
Just to underscore that it's difficult to get right, I found out recently
that hacking doesn't do a grea
On 2014-12-09 07:29:31 -0800 (-0800), Monty Taylor wrote:
> I DO like something warning about commit subject length ... but maybe
> that should be a git-review function or something.
[...]
How about a hook in Gerrit to refuse commits based on some simple
(maybe even project-specific) rules?
--
Je
On 12/09/2014 11:15 AM, Brian Curtis wrote:
> On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote:
>> - [H305 H306 H307] Organize your imports according to the `Import order
>> template`_ and `Real-world Import Order Examples`_ below.
>>
>> I think these remain reasonable guidelines, but H302 is ex
On Tue, Dec 9, 2014 at 9:05 AM, Sean Dague wrote:
> - [H305 H306 H307] Organize your imports according to the `Import order
> template`_ and `Real-world Import Order Examples`_ below.
>
> I think these remain reasonable guidelines, but H302 is exceptionally
> tricky to get right, and we keep not
On 12/09/2014 03:39 AM, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason to pre
On Tue, Dec 9, 2014 at 12:39 PM, Sean Dague wrote:
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally.
>
I do run them locally using git-review custom script features which would
launch a flake8 before sendi
On 12/09/2014 09:11 AM, Doug Hellmann wrote:
>
> On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
>
>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>
>> 1 - the entire H8* group. This doesn't function on python code, it
>> functions on git commit message, which make
On Tue, Dec 09, 2014 at 08:16:34AM -0500, Sean Dague wrote:
> On 12/09/2014 07:32 AM, Sahid Orentino Ferdjaoui wrote:
> > On Tue, Dec 09, 2014 at 06:39:43AM -0500, Sean Dague wrote:
> >> I'd like to propose that for hacking 1.0 we drop 2 groups of rules
> >> entirely.
> >>
> >> 1 - the entire H8*
On Dec 9, 2014, at 6:39 AM, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason
On Tue, Dec 09 2014, Sean Dague wrote:
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would be a reason to prevent us from not rerunning tests on commit
> message changes (something we could do
On 12/09/2014 07:32 AM, Sahid Orentino Ferdjaoui wrote:
> On Tue, Dec 09, 2014 at 06:39:43AM -0500, Sean Dague wrote:
>> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>>
>> 1 - the entire H8* group. This doesn't function on python code, it
>> functions on git commit m
On Tue, Dec 09, 2014 at 06:39:43AM -0500, Sean Dague wrote:
> I'd like to propose that for hacking 1.0 we drop 2 groups of rules entirely.
>
> 1 - the entire H8* group. This doesn't function on python code, it
> functions on git commit message, which makes it tough to run locally. It
> also would
30 matches
Mail list logo
