nova team mailing list archive

[Joseph Heck <heckj@xxxxxxx>]

I took a stab this weekend. Getting everything set up to do the cleaning on my laptop (MacOS X) took me some noodling around (I'm not super familiar with Bzr/Launchpad). I documented all the steps if it helps anyone else get into cleaning:

http://wiki.openstack.org/HackingNovaMacOSX

What I ran into though is that I didn't have the full set of tests working correctly before I dug into the codebase. Hudson wasn't too much more help, as the downstream unit tests with coverage appeared to be in much worse shape than my laptop (http://hudson.openstack.org/job/nova-coverage/35/console).

I did some light formatting clean up work, but without all the tests all 100%, I was concerned about doing anything deeper (like changing names in methods, etc).

The test that's failing is nova.tests.auth_unittest.AuthTestCase.test_209_can_generate_x509 - my cleaning work was in nova/endpoints/cloud.py (added to Etherpad page). 

I submitted a merge request with the results - hopefully that's the correct way to do this... happy to have feedback. 

-joe 

On Aug 7, 2010, at 5:08 PM, Eric Day wrote:
> Are you looking for some easy tasks to do so you can get involved
> with Nova? We've created some low hanging fruit blueprints to get
> started with:
> 
> https://edge.launchpad.net/nova/+milestone/low-hanging-fruit
> 
> One of these tasks is cleaning up the pylint and pep8 violations. You
> can find our current stats at:
> 
> http://hudson.openstack.org/job/nova-pep8/
> http://hudson.openstack.org/job/nova-pylint/
> 
> Cleaning up these violations will help normalize the code and increase
> readability. Some of you may have noticed a branch went in starting
> this, and I'm going to continue cleaning files as I have time. If you
> want to help, pick a file and clean! I setup an etherpad so we can
> claim files to prevent duplicating work. I also listed the commands
> you can use to check the files manually as you work on them.
> 
> http://etherpad.openstack.org/nova-pylint
> 
> On a related note, I'd like to propose we not merge any new branches
> if it increases the pylint/pep8 violation count. This allows for
> branches fixing old code to not require conversion yet, but any new,
> original code should conform. Monty is working on the merge system
> to make this rule automated. What do folks think?
> 
> If we all grab a few files we can get down to zero violations in no
> time. :)