Mailing List Archive

Well - there are two choices... you can upgrade to 1.1, or you can put
in an entry into tox.ini, changing:

deps=pep8

to

deps = pep8==0.6.1

We're working on getting this to the point where the pep8 version in
test-requires is honored.

On 05/25/2012 04:46 PM, Dan Wendlandt wrote:
> Hi Monty,
>
> A recent commit to Quantum failed due to pep8 errors that were not
> related to the
> patch: https://jenkins.openstack.org/job/check-quantum-pep8/1/console
>
> After some digging, I noticed that these errors were due to the fact
> that Jenkins is using pep8 version 1.1, rather than the pep8 0.6.1 that
> is specified in quantum's tools/test-requires
>
> [TOX] ***installing dependencies: pep8
> [TOX] /home/jenkins/workspace/check-quantum-pep8/.tox/pep8/log$ ../bin/pip install --download-cache=/home/jenkins/workspace/check-quantum-pep8/.tox/_download pep8
> Downloading/unpacking pep8
> Downloading pep8-1.1.tar.gz
> Storing download in cache at /home/jenkins/workspace/check-quantum-pep8/.tox/_download/http%3A%2F%2Fpypi.openstack.org <http://2Fpypi.openstack.org>%2Fpep8%2Fpep8-1.1.tar.gz
> Running setup.py egg_info for package pep8
>
>
>
> We can pretty easily clean up the pep8 errors and change test-requires,
> but I wanted to check with you first to see if the change to 1.1 is
> intentional and permanent. Thanks,
>
> Dan
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com <http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

On Fri, 2012-05-25 at 17:38 -0400, Monty Taylor wrote:
> Well - there are two choices... you can upgrade to 1.1, or you can put
> in an entry into tox.ini, changing:
>
> deps=pep8
>
> to
>
> deps = pep8==0.6.1

Pep8 errors in the foxinsocks test and the cisco plugin fixed here:
https://review.openstack.org/#/c/7813/

Happy Hacking!

7-11


--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

Hi Monty,

So moving forward it seems that we have two options here:

1) add hardcoded pep8 version in tox.ini to match the hardcoded version in
tools/tests-requires. Benefit: avoid randomly having all reviews get
rejected by CI infrastructure whenever the CI infrastructure happens to
pick up a new version of pep8.

2) remove hardcoded pep8 version in tools/test-requires to match tox.ini.
Benefit: we're always using the latest pep8 version (and therefore closer
to the goal of more readable code) and people have a strong incentive to
clean up the code (since its blocking their commits).

While my preference was originally #1, as it gives more predictability.
However, if people do not monitor for new versions of pep8, we get stuck
on an old version (currently 0.6.1). Jason has persuaded me that given
that pep8 clean-ups tend to be quite quick to code and review, that #2 may
well be a better option. I'll plan on doing that unless anyone from the
quantum or CI teams has a major concern. The side-effect is that
developers may submit patches that get rejected because pep8 on their
system is out of date, at which time they will need to update their version
(or recreate their tox env. from scratch). Seems fine with me.

Dan



On Fri, May 25, 2012 at 2:38 PM, Monty Taylor <mordred@inaugust.com> wrote:

> Well - there are two choices... you can upgrade to 1.1, or you can put
> in an entry into tox.ini, changing:
>
> deps=pep8
>
> to
>
> deps = pep8==0.6.1
>
> We're working on getting this to the point where the pep8 version in
> test-requires is honored.
>
> On 05/25/2012 04:46 PM, Dan Wendlandt wrote:
> > Hi Monty,
> >
> > A recent commit to Quantum failed due to pep8 errors that were not
> > related to the
> > patch: https://jenkins.openstack.org/job/check-quantum-pep8/1/console
> >
> > After some digging, I noticed that these errors were due to the fact
> > that Jenkins is using pep8 version 1.1, rather than the pep8 0.6.1 that
> > is specified in quantum's tools/test-requires
> >
> > [TOX] ***installing dependencies: pep8
> > [TOX] /home/jenkins/workspace/check-quantum-pep8/.tox/pep8/log$
> ../bin/pip install
> --download-cache=/home/jenkins/workspace/check-quantum-pep8/.tox/_download
> pep8
> > Downloading/unpacking pep8
> > Downloading pep8-1.1.tar.gz
> > Storing download in cache at
> /home/jenkins/workspace/check-quantum-pep8/.tox/_download/http%3A%2F%
> 2Fpypi.openstack.org <http://2Fpypi.openstack.org
> >%2Fpep8%2Fpep8-1.1.tar.gz
> > Running setup.py egg_info for package pep8
> >
> >
> >
> > We can pretty easily clean up the pep8 errors and change test-requires,
> > but I wanted to check with you first to see if the change to 1.1 is
> > intentional and permanent. Thanks,
> >
> > Dan
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com <http://www.nicira.com>
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

On 06/02/2012 02:25 PM, Dan Wendlandt wrote:
> Hi Monty,
>
> So moving forward it seems that we have two options here:
>
> 1) add hardcoded pep8 version in tox.ini to match the hardcoded version
> in tools/tests-requires. Benefit: avoid randomly having all reviews get
> rejected by CI infrastructure whenever the CI infrastructure happens to
> pick up a new version of pep8.
>
> 2) remove hardcoded pep8 version in tools/test-requires to match
> tox.ini. Benefit: we're always using the latest pep8 version (and
> therefore closer to the goal of more readable code) and people have a
> strong incentive to clean up the code (since its blocking their commits)..
>
> While my preference was originally #1, as it gives more predictability.
> However, if people do not monitor for new versions of pep8, we get
> stuck on an old version (currently 0.6.1). Jason has persuaded me that
> given that pep8 clean-ups tend to be quite quick to code and review,
> that #2 may well be a better option.

My preference was for #1 as well, but the more I think about it, the
more I think that we should be pretty aggressive with tracking pep8
stuff anyway.

> I'll plan on doing that unless
> anyone from the quantum or CI teams has a major concern. The
> side-effect is that developers may submit patches that get rejected
> because pep8 on their system is out of date, at which time they will
> need to update their version (or recreate their tox env. from scratch).
> Seems fine with me.
>
> Dan
>
>
>
> On Fri, May 25, 2012 at 2:38 PM, Monty Taylor <mordred@inaugust.com
> <mailto:mordred@inaugust.com>> wrote:
>
> Well - there are two choices... you can upgrade to 1.1, or you can put
> in an entry into tox.ini, changing:
>
> deps=pep8
>
> to
>
> deps = pep8==0.6.1
>
> We're working on getting this to the point where the pep8 version in
> test-requires is honored.
>
> On 05/25/2012 04:46 PM, Dan Wendlandt wrote:
> > Hi Monty,
> >
> > A recent commit to Quantum failed due to pep8 errors that were not
> > related to the
> > patch: https://jenkins.openstack.org/job/check-quantum-pep8/1/console
> >
> > After some digging, I noticed that these errors were due to the fact
> > that Jenkins is using pep8 version 1.1, rather than the pep8 0.6.1
> that
> > is specified in quantum's tools/test-requires
> >
> > [TOX] ***installing dependencies: pep8
> > [TOX] /home/jenkins/workspace/check-quantum-pep8/.tox/pep8/log$
> ../bin/pip install
> --download-cache=/home/jenkins/workspace/check-quantum-pep8/..tox/_download
> pep8
> > Downloading/unpacking pep8
> > Downloading pep8-1.1.tar.gz
> > Storing download in cache at
> /home/jenkins/workspace/check-quantum-pep8/.tox/_download/http%3A%2F%2Fpypi.openstack.org
> <http://2Fpypi.openstack.org>
> <http://2Fpypi.openstack.org>%2Fpep8%2Fpep8-1.1.tar.gz
> > Running setup.py egg_info for package pep8
> >
> >
> >
> > We can pretty easily clean up the pep8 errors and change
> test-requires,
> > but I wanted to check with you first to see if the change to 1.1 is
> > intentional and permanent. Thanks,
> >
> > Dan
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com <http://www.nicira.com>
> <http://www.nicira.com>
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com <http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

On 06/03/2012 02:03 AM, Monty Taylor wrote:
> On 06/02/2012 02:25 PM, Dan Wendlandt wrote:
>> Hi Monty,
>>
>> So moving forward it seems that we have two options here:
>>
>> 1) add hardcoded pep8 version in tox.ini to match the hardcoded version
>> in tools/tests-requires. Benefit: avoid randomly having all reviews get
>> rejected by CI infrastructure whenever the CI infrastructure happens to
>> pick up a new version of pep8.
>>
>> 2) remove hardcoded pep8 version in tools/test-requires to match
>> tox.ini. Benefit: we're always using the latest pep8 version (and
>> therefore closer to the goal of more readable code) and people have a
>> strong incentive to clean up the code (since its blocking their commits)..
>>
>> While my preference was originally #1, as it gives more predictability.
>> However, if people do not monitor for new versions of pep8, we get
>> stuck on an old version (currently 0.6.1). Jason has persuaded me that
>> given that pep8 clean-ups tend to be quite quick to code and review,
>> that #2 may well be a better option.
> My preference was for #1 as well, but the more I think about it, the
> more I think that we should be pretty aggressive with tracking pep8
> stuff anyway.
I am in favour of #1 at the moment. In Folsom there was considerable
effort to deal with pep8. Essex stable is a side branch and will at some
time or another be replaced by Folsom. Adding all of the pep8 changes
into a stable branch could lead to some problems (it is very low risk).
Nonetheless, if the stricter pep8 is chosen, then why not just use
Folsom-1 as the stable essex (there were 2 activities on this - bug
fixes and pep8 support)
>> I'll plan on doing that unless
>> anyone from the quantum or CI teams has a major concern. The
>> side-effect is that developers may submit patches that get rejected
>> because pep8 on their system is out of date, at which time they will
>> need to update their version (or recreate their tox env. from scratch).
>> Seems fine with me.
>>
>> Dan
>>
>>
>>
>> On Fri, May 25, 2012 at 2:38 PM, Monty Taylor<mordred@inaugust.com
>> <mailto:mordred@inaugust.com>> wrote:
>>
>> Well - there are two choices... you can upgrade to 1.1, or you can put
>> in an entry into tox.ini, changing:
>>
>> deps=pep8
>>
>> to
>>
>> deps = pep8==0.6.1
>>
>> We're working on getting this to the point where the pep8 version in
>> test-requires is honored.
>>
>> On 05/25/2012 04:46 PM, Dan Wendlandt wrote:
>> > Hi Monty,
>> >
>> > A recent commit to Quantum failed due to pep8 errors that were not
>> > related to the
>> > patch: https://jenkins.openstack.org/job/check-quantum-pep8/1/console
>> >
>> > After some digging, I noticed that these errors were due to the fact
>> > that Jenkins is using pep8 version 1.1, rather than the pep8 0.6.1
>> that
>> > is specified in quantum's tools/test-requires
>> >
>> > [TOX] ***installing dependencies: pep8
>> > [TOX] /home/jenkins/workspace/check-quantum-pep8/.tox/pep8/log$
>> ../bin/pip install
>> --download-cache=/home/jenkins/workspace/check-quantum-pep8/..tox/_download
>> pep8
>> > Downloading/unpacking pep8
>> > Downloading pep8-1.1.tar.gz
>> > Storing download in cache at
>> /home/jenkins/workspace/check-quantum-pep8/.tox/_download/http%3A%2F%2Fpypi.openstack.org
>> <http://2Fpypi.openstack.org>
>> <http://2Fpypi.openstack.org>%2Fpep8%2Fpep8-1.1.tar.gz
>> > Running setup.py egg_info for package pep8
>> >
>> >
>> >
>> > We can pretty easily clean up the pep8 errors and change
>> test-requires,
>> > but I wanted to check with you first to see if the change to 1.1 is
>> > intentional and permanent. Thanks,
>> >
>> > Dan
>> >
>> >
>> > --
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > Dan Wendlandt
>> > Nicira, Inc: www.nicira.com<http://www.nicira.com>
>> <http://www.nicira.com>
>> > twitter: danwendlandt
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >
>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Dan Wendlandt
>> Nicira, Inc: www.nicira.com<http://www.nicira.com>
>> twitter: danwendlandt
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>


--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

On Sat, Jun 2, 2012 at 8:45 PM, Gary Kotton <gkotton@redhat.com> wrote:

>
>>> My preference was for #1 as well, but the more I think about it, the
>> more I think that we should be pretty aggressive with tracking pep8
>> stuff anyway.
>>
> I am in favour of #1 at the moment. In Folsom there was considerable
> effort to deal with pep8. Essex stable is a side branch and will at some
> time or another be replaced by Folsom. Adding all of the pep8 changes into
> a stable branch could lead to some problems (it is very low risk).

Nonetheless, if the stricter pep8 is chosen, then why not just use
> Folsom-1 as the stable essex (there were 2 activities on this - bug fixes
> and pep8 support)


Gary and I chatted about this on IRC. I think we agree that we won't
backport pep8 fixes or other clean-up to stable branches. Stable branches
should be for significant bug fixes only.

He's my suggested approach. We drop any strict pep8 version in the master
branch code, meaning that we always track the lastest pep8.

When we cut a stable branch, a pep8 update that flags new issues will cause
problems for a stable branch, so we can hardcode the pep8 version for a
stable branch to the version that was current when that code was released.
This way we don't need to backport pep8 to stable branches.

Here's a review to remove the hardcoded 0.6.1 version from
tools/test-requires: https://review.openstack.org/#/c/8243/1

dan



>
> I'll plan on doing that unless
>>> anyone from the quantum or CI teams has a major concern. The
>>> side-effect is that developers may submit patches that get rejected
>>> because pep8 on their system is out of date, at which time they will
>>> need to update their version (or recreate their tox env. from scratch).
>>> Seems fine with me.
>>>
>>> Dan
>>>
>>>
>>>
>>> On Fri, May 25, 2012 at 2:38 PM, Monty Taylor<mordred@inaugust.com
>>> <mailto:mordred@inaugust.com>> wrote:
>>>
>>> Well - there are two choices... you can upgrade to 1.1, or you can
>>> put
>>> in an entry into tox.ini, changing:
>>>
>>> deps=pep8
>>>
>>> to
>>>
>>> deps = pep8==0.6.1
>>>
>>> We're working on getting this to the point where the pep8 version in
>>> test-requires is honored.
>>>
>>> On 05/25/2012 04:46 PM, Dan Wendlandt wrote:
>>> > Hi Monty,
>>> >
>>> > A recent commit to Quantum failed due to pep8 errors that were not
>>> > related to the
>>> > patch: https://jenkins.openstack.org/**job/check-quantum-pep8/1/*
>>> *console<https://jenkins.openstack.org/job/check-quantum-pep8/1/console>
>>> >
>>> > After some digging, I noticed that these errors were due to the
>>> fact
>>> > that Jenkins is using pep8 version 1.1, rather than the pep8 0.6.1
>>> that
>>> > is specified in quantum's tools/test-requires
>>> >
>>> > [TOX] ***installing dependencies: pep8
>>> > [TOX] /home/jenkins/workspace/check-**quantum-pep8/.tox/pep8/log$
>>> ../bin/pip install
>>> --download-cache=/home/**jenkins/workspace/check-**
>>> quantum-pep8/..tox/_download
>>> pep8
>>> > Downloading/unpacking pep8
>>> > Downloading pep8-1.1.tar.gz
>>> > Storing download in cache at
>>> /home/jenkins/workspace/check-**quantum-pep8/.tox/_download/**
>>> http%3A%2F%2Fpypi.openstack.**org <http://2Fpypi.openstack.org>
>>> <http://2Fpypi.openstack.org>
>>> <http://2Fpypi.openstack.org>%**2Fpep8%2Fpep8-1.1.tar.gz
>>> > Running setup.py egg_info for package pep8
>>> >
>>> >
>>> >
>>> > We can pretty easily clean up the pep8 errors and change
>>> test-requires,
>>> > but I wanted to check with you first to see if the change to 1.1
>>> is
>>> > intentional and permanent. Thanks,
>>> >
>>> > Dan
>>> >
>>> >
>>> > --
>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> > Dan Wendlandt
>>> > Nicira, Inc: www.nicira.com<http://www.**nicira.com<http://www.nicira.com>
>>> >
>>> <http://www.nicira.com>
>>> > twitter: danwendlandt
>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >
>>>
>>>
>>>
>>>
>>> --
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> Dan Wendlandt
>>> Nicira, Inc: www.nicira.com<http://www.**nicira.com<http://www.nicira.com>
>>> >
>>> twitter: danwendlandt
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>
> --
> Mailing list: https://launchpad.net/~**netstack<https://launchpad.net/~netstack>
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~**netstack<https://launchpad.net/~netstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

+1 :D

On Jun 6, 2012, at 6:15 PM, Dan Wendlandt wrote:



On Sat, Jun 2, 2012 at 8:45 PM, Gary Kotton <gkotton@redhat.com<mailto:gkotton@redhat.com>> wrote:

My preference was for #1 as well, but the more I think about it, the
more I think that we should be pretty aggressive with tracking pep8
stuff anyway.
I am in favour of #1 at the moment. In Folsom there was considerable effort to deal with pep8. Essex stable is a side branch and will at some time or another be replaced by Folsom. Adding all of the pep8 changes into a stable branch could lead to some problems (it is very low risk).
Nonetheless, if the stricter pep8 is chosen, then why not just use Folsom-1 as the stable essex (there were 2 activities on this - bug fixes and pep8 support)

Gary and I chatted about this on IRC. I think we agree that we won't backport pep8 fixes or other clean-up to stable branches. Stable branches should be for significant bug fixes only.

He's my suggested approach. We drop any strict pep8 version in the master branch code, meaning that we always track the lastest pep8.

When we cut a stable branch, a pep8 update that flags new issues will cause problems for a stable branch, so we can hardcode the pep8 version for a stable branch to the version that was current when that code was released. This way we don't need to backport pep8 to stable branches.

Here's a review to remove the hardcoded 0.6.1 version from tools/test-requires: https://review.openstack.org/#/c/8243/1

dan



I'll plan on doing that unless
anyone from the quantum or CI teams has a major concern. The
side-effect is that developers may submit patches that get rejected
because pep8 on their system is out of date, at which time they will
need to update their version (or recreate their tox env. from scratch).
Seems fine with me.

Dan



On Fri, May 25, 2012 at 2:38 PM, Monty Taylor<mordred@inaugust.com<mailto:mordred@inaugust.com>
<mailto:mordred@inaugust.com<mailto:mordred@inaugust.com>>> wrote:

Well - there are two choices... you can upgrade to 1.1, or you can put
in an entry into tox.ini, changing:

deps=pep8

to

deps = pep8==0.6.1

We're working on getting this to the point where the pep8 version in
test-requires is honored.

On 05/25/2012 04:46 PM, Dan Wendlandt wrote:
> Hi Monty,
>
> A recent commit to Quantum failed due to pep8 errors that were not
> related to the
> patch: https://jenkins.openstack.org/job/check-quantum-pep8/1/console
>
> After some digging, I noticed that these errors were due to the fact
> that Jenkins is using pep8 version 1.1, rather than the pep8 0.6.1
that
> is specified in quantum's tools/test-requires
>
> [TOX] ***installing dependencies: pep8
> [TOX] /home/jenkins/workspace/check-quantum-pep8/.tox/pep8/log$
../bin/pip install
--download-cache=/home/jenkins/workspace/check-quantum-pep8/..tox/_download
pep8
> Downloading/unpacking pep8
> Downloading pep8-1.1.tar.gz
> Storing download in cache at
/home/jenkins/workspace/check-quantum-pep8/.tox/_download/http%3A%2F%2Fpypi.openstack.org<http://2Fpypi.openstack.org/>
<http://2Fpypi.openstack.org<http://2Fpypi.openstack.org/>>
<http://2Fpypi.openstack.org<http://2Fpypi.openstack.org/>>%2Fpep8%2Fpep8-1.1.tar.gz
> Running setup.py egg_info for package pep8
>
>
>
> We can pretty easily clean up the pep8 errors and change
test-requires,
> but I wanted to check with you first to see if the change to 1.1 is
> intentional and permanent. Thanks,
>
> Dan
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com<http://www.nicira.com/><http://www.nicira.com<http://www.nicira.com/>>
<http://www.nicira.com<http://www.nicira.com/>>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com/><http://www.nicira.com<http://www.nicira.com/>>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~



--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com/>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp