[Freeipa-devel] [PATCHES] jderose 0009-0019

[Rob Crittenden]

Jason Gerard DeRose wrote:
> On Mon, 2009-02-16 at 15:50 -0500, Rob Crittenden wrote:
>> Jason Gerard DeRose wrote:
>>> These patches finish my (initial) cleanup and testing of Andrew's
>>> request authority plugins.  These have been tested against a CA server
>>> Andrew has running (only accessible inside Red Hat firewall).  The tests
>>> I ran aren't exhaustive by any means, but it's a start.
>>>
>>> A few other noteworthy changes:
>>>
>>> 1) I added a mechanism for an entire plugin module to be conditionally
>>> loaded.  Previously individual plugins (classes) could be conditionally
>>> registered, but there wasn't a way to conditionally skip the entire
>>> module.  Now you can raise errors2.SkipPluginModule.
>>>
>>> For example, if your plugin is included in the built-in freeIPA plugins
>>> but is only optionally enabled, you can use SkipPluginModule so that
>>> nothing in your module after the point where you raise SkipPluginModule
>>> gets processed:
>>>
>>>         from ipalib import api, SkipPluginModule
>>>         if api.env.enable_ra is not True:
>>>             # In this case, abort loading this plugin module...
>>>             raise SkipPluginModule(reason='env.enable_ra is not True')
>>>         
>>>         # The remaining is only processed when env.enable_ra is True...
>>>         
>>>         # So we don't get an import error here!
>>>         import not_installed_python_package
>>>
>>> 2) I added a place-holder directory for integration tests: checks/
>>> Inside is my still rather hacky check-ra.py script I was using to test
>>> the ra backend plugin.  I'll send another email shortly with some
>>> thoughts about integration testing.
>>>
>>>
>>> P.S.: I put the patches in a tarball because it seems that Evolution is
>>> Windows-ifying the line endings in my attachments.
>> I'm having a really hard time reviewing these since the patches aren't 
>> cumulative but build upon each other. Since patches 0001-0007 haven't 
>> been applied yet it isn't possible to cleanly apply these either.
>>
>> I'll see if I can slurp them all in together and make a single, unified 
>> patch so I can see what is going on.
> 
> Am I not submitting them correctly?  What should I do differently?

Well, for upstream it's easier to review the final patch rather than all 
the small patches it is made up of. You can still do incremental 
patching and then group it all together with git rebase -i

The man page on it is so-so, this page describes it a little: 
http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive

Basically you just squash all your small commits into one big one. You 
can still save all the commit messages.

Note that this forces you to rebase your tree from the tip which isn't 
necessarily a bad thing as it ensures that the patch(es) will apply cleanly.

rob