On 03/12/2013 11:07 AM, Don Zickus wrote:
On Tue, Mar 12, 2013 at 12:59:14AM -0300, Lucas Meneghel Rodrigues
wrote:
> On Fri, Mar 8, 2013 at 3:16 PM, Don Zickus <dzickus(a)redhat.com> wrote:
>> Hi Folks,
>>
>> Recently a bunch of autotest and beaker folks have been discussing how to get
>> an autotest client working under beaker (namely Nick, Dan, Bill from beaker and
>> Lucas, Cleber, Ademar from autotest).
>>
>> A long time ago Jan Stancek whipped up some code to do that based on some
>> discussions we both had. I later modified a bunch of his code and came up with
>> these patches.
>>
>> I lasted touched these patches back in August 2012. I never finished polishing
>> them off or completed my testing due to other Red Hat obligations.
>>
>> I am presenting these patches as a starting point for discussions as to how Jan
>> and myself solved various problems. They are very much 'beta' patches
(there
>> has been a lot of testing so they were stable at one point).
>>
>> Unfortunately, I don't remember how all the pieces worked so instead of
>> breaking the files into digestable chunks, I am just submitting whole files as
>> new (well the first patch is a 'patch').
>>
>> I rebased them on to the latest autotest/HEAD as of today. Though I didn't
>> test them.
>>
>> Please be kind. I am cross-posting to various mailing lists to let anyone
>> interested participate.
>>
>> The end goal is to have autotest client work with the beaker server smoothly.
>> This would allow various autotest projects to leverage the
>> provisioning/inventorying mechanisms provided by beaker for various labs.
>
> These patches look like a great start. There are some coding style
> inadequacies, that will need to be addressed, mainly:
Thanks. I have to modify them to the new beaker API, but my most
important piece is the bootstrapping hack.
If that is a no-go, then I have to come up with another solution first.
Sure. Having some harnesses to have a bootstrap stage is fine. If
anything, bootstrap methods could be implemented in the other harnesses
as no-ops, just for the sake of uniformity.
So we may proceeed with this idea. In fact, I like the fact it is simple
and doesn't require a daemon running.
>
> 1) Fix usage of CamelCase. The only exception are class names.
My python-foo is so limited, I don't know what CamelCase is. :-(
CamelCase is naming classes and methods with a mixture of
uppercase/lowercase characters. In autotest, it is fine for class names,
but not for methods, attributes and other general variable names. For
those, all_lowercase_with_underscores is recommended.
> 2) Docstring format
Example:
def foo(param1, param2):
"""
Summary line.
Long description of method foo.
@param param1: A thing called param1 that is used for a bunch of stuff
that has methods bar() and baz() which raise SpamError if
something goes awry.
@return a list of integers describing changes in a source tree
...
"""
> 3) Use of old style classes
Also something simple. Instead of doing
class Foo:
pass
Do instead
class Foo(object):
pass
Shouldn't affect the outcome (although I've seen cases where it brings a
quirk or two) and makes usage of super() safer.
More things I don't know what they are. :-(
>
> There are other small issues, mostly related to PEP8 here and there.
> That all said, I'm going patch by patch checking the general goals,
> and running some static checking to shake up small bugs.
And PEP8 is also another new thing for me. :-(
PEP8 is a sort of base reference for python coding style.
http://www.python.org/dev/peps/pep-0008/
The autotest code style inherits from it, and the differences are
outlined in the coding style document:
https://github.com/autotest/autotest/blob/master/CODING_STYLE
I offer to pick up your patches, fix all those inadequacies and small
bugs, then have a branch ready from where you can pull and resume work
from there. Does that sound good to you?