[Freeipa-devel] tree reorganization proposal

[Dmitri Pal]

Jason Gerard DeRose wrote:
> On Tue, 2009-01-27 at 14:34 -0500, Rob Crittenden wrote:
>   
>> Now that I've muddled things up by importing Jason's tree into the 
>> master branch, here is how I propose we clean it up.
>>
>> I'm purposely excluding Makefiles for now. I'm not sure they are going 
>> to be needed as we can probably cover the installation as part of 
>> setup.py. I'm particularly worried about my suggestion of 
>> ipaserver/tools. I'm not sure how flexible the python setuputils is to 
>> not include subdirs when it creates packages, and to move things around. 
>> This is mostly based on cosmetic and tidiness reasons. I still need to 
>> figure out how to build rpms from these.
>>
>> mkdir ipaserver/install
>> mv ipa-server/ipaserver/* ipaserver/install
>>
>> mkdir ipaserver/tools
>> mkdir ipaserver/tools/man
>> mv ipa-server/ipa-install/ipa-* ipaserver/tools
>> mv ipa-server/ipa-install/ipactl ipaserver/tools
>> mv ipa-server/ipa-upgradeconfig ipaserver/tools
>> mv ipa-server/ipa-ldap-updater ipaserver/tools
>> mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools
>> mv ipa-server/man/* ipaserver/tools/man
>>
>> mv ipa-server/ipa-install/share ipaserver
>> mv ipa-server/ipa-install/updates/* ipaserver/updates
>>
>> mkdir ipaserver/install
>> mv ipa-server/ipaserver/* ipa-server/install
>>
>> mv ipa-server/selinux ipaserver
>> mv ipa-server/ipa-kpasswd ipaserver
>> mv ipa-server/ipa-slapi-plugins ipaserver
>>
>> I think after this we can remove everything in ipa-server.
>>
>> The resulting directories will look something like:
>>
>> ipalib/
>> ipa-python/
>> ipaserver/tools/
>> ipaserver/
>> ipaserver/tools/
>> ipaserver/tools/man/
>> ipaserver/share/
>> ipaserver/install/
>> ipaserver/updates/
>> ipaserver/ipa-kpasswd/
>> ipaserver/ipa-slapi-plugins/
>> ipaserver/selinux/
>> ipawebui/
>> tests/
>> ipa-client/
>>
>> ipa-admintools is going away and the radius tools and functionality will 
>> be folded into the server as time permits.
>>
>> I suspect that ipa-python will be folded into ipalib at some point. Most 
>> of it is already re-implemented as it is. It very much depends on what 
>> the client installer will look like and whether we will include one in 
>> this tree or require people to use SSSD.
>>
>> Lots of this is just moving things from ipa-server into ipaserver which 
>> make Jason wince.
>>     
>
> Well, okay, I'll admit it does.  I really appreciate the work you've
> done on this, Rob... this looks like lot of work, and tedious at that.
>
> However, I still question the value of this type of merge.  I might be
> the only one who feels this way, but I think this is going to cost us a
> lot of time.  IMHO, it's much more productive to merge what's needed
> than to merge everything and then slowly figure out what isn't needed.
>
> Aside from the issue of having to slowly remove depreciated code, I
> guess I see two possible approaches here:
>
> We could:
>
>         1. Merge v2 code into v1.
>         
>         2. Write a layer to glue the v1 code into v2 for features we are
>         missing in v2.
>         
>         3. Someday re-write the v1 code we are using or at least add
>         some badly needed unit tests (not to mention fixing various
>         Unicode/i18n bugs).
>
> Or we could:
>
>         1. Using the v1 code as a reference, quickly implement missing
>         functionality in v2, building this functionality up layer by
>         layer with good unit tests and correct Unicode/i18n behavior
>         from the get-go.
>
> In this particular situation, I think the second approach will only take
> 25%-50% of the time that the first would.
>
> Also, as far as I know, the only major piece from v1 that we're missing
> in v2 is the install/configure functionality.  Is this correct?  And
> this functionality really needs to be re-implemented to be
> plugin-friendly anyway.
>
> And aren't we planning on moving the DS plugins into a separate tree
> anyway?
>
> Grateful yet concerned,
> Jason
>
>   
I agree with Jason rationale.
IMO there is not much left in the IPA v2 from IPA v2 so may be we should 
merge what makes sense from IPA v1 to the new code rather thank vice versa.
But I am not an expert.

Thanks
Dmitri

>> rob
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>     
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel