On 07/14/2009 05:02 PM, James Cammarata wrote:
On Tue, 14 Jul 2009 16:51:53 -0400, Michael
DeHaan<mdehaan(a)redhat.com>
wrote:
> Here's a war everyone can get behind.
>
> I suspect most FIXME comments in Cobbler are about things that don't
> matter anymore.
>
> Some of these things are reminders for future bits -- like 2.0 features,
> that may not be implemented that we need to implement.
>
> I'm going to be working on removing the ones that don't, and fixing the
> things that need to be fixed if they do.
>
> [mdehaan@localhost cobbler]$ grep "FIXME" *.py | wc -l
> 118
> [mdehaan@localhost cobbler]$ pwd
> /home/mdehaan/cg/cobbler/cobbler
> [mdehaan@localhost cobbler]$ cd modules
> [mdehaan@localhost modules]$ grep "FIXME" *.py | wc -l
> 23
>
> If you'd like to help us clean up the shop, help is welcome, though I
> suspect I'm the one who would know which ones are most ignorable.
>
> Mostly it would be about removing comments so that once again we can
> tell by grepping for FIXME whether the code is "done", and we can use
> that for a criteria about whether 2.0 is close to done or not.
>
A large number of FIXME's that I see in the code are things that have
already been fixed, so hopefully this will be a short war :)
I think so. Hopefully Shock and Awe will be successful and we will not
need a Surge.
Also I suspect a lot of them may be related to network objects being
half finished, which also reduces our LOC by moving that aside :)
And in terms of doing stuff right, a few things also come to mind:
* zero tolerance on methods without pydoc
* finally commenting what the FIELDS datastructure does
After we get that out of the way, then, yes, I think we are ready to do
the CLI remoting.
One thing I just found today was that modules and triggers weren't
getting passed the logger, so we do have some cleanup to do there... as
well as testing all the modules. Which is a good thing to do anyway
since they don't get fully combed through as often as some of the other
pieces of code.
They have a bit of a legacy of leaving return codes instead of
exceptions on failure, too, which I think we can clean up... no point in
hiding useful tracebacks there.
--Michael