Darren J Moffat wrote: > Lukas Rovensky wrote: >> Hi all, >> >> as promised, I explored the options we have concerning Samba 3.4 x >> Mozilla LDAP 6 C SDK. As you can see below there is currently no >> ideal solution and a compromise will be needed. From the business >> point of view we really would like to be able to put Samba 3.4 to >> S10U9 -- we are already getting requests for interoperability with >> Windows 7, [1] and again the answer is Samba 3.4. >> >> Here is a list of options, which were discussed off-channel -- any >> feedback is welcome: >> >> 1) Leave the PSARC case as it is and ask PSARC members for the vote >> and opinion as mentioned by Darren. This is currently the preferred >> option by the I-team. >> >> 2) Use OpenLDAP, which is already integrated in Nevada and use Mozilla >> LDAP 6 C SDK as Samba's private component in S10. This will have a >> clear disadvantage of having different Samba's in S10 and Nevada. Any >> LDAP related issue will have to be solved separately for Nevada and >> S10 and the maintenance cost will increase. >> >> 3) Mark the Mozilla LDAP 6 C SDK a "public" component in Nevada. Jiri >> can still help with the integration but we will need a commitment from >> the Naming folks that they will support this component (at least on >> level C). The LDAP 6 C SDK still shall be Samba's private component >> in S10. However, based on the discussion with Naming engineers this >> would basically mean an LDAP C SDK update in Nevada, a separate PSARC >> case will be required and such solution will certainly take longer >> than the time frame we have for S10U9. Besides, we still may have a >> problem with getting resources from the Naming team to assist with >> this task. >> >> 4) Use OpenLDAP instead of Mozilla LDAP 6 C SDK. This will work in >> Nevada but will represent a problem for S10. As per the experiments >> performed by Jiri -- integration of OpenLDAP to S10 (as private >> Samba's component) is not trivial and this will also mean to integrate >> much bigger beast than just the LDAP C SDK. OpenLDAP is being changed >> rather often, so this will also bring an additional burden for the >> I-team to maintain it as part of Samba in S10. We will have a problem >> to find resources to do this work (both in terms of people and time). > > The ARC can't answer this for you, this is a business decision based on > resources and the risks of S10 and Nevada source trees diverging in this > area. The above information is great background but the project team > should pick one as their proposal (I think you are saying option 1) and > ask the ARC's opinion. > Hi Darren,
thanks for the clarification. As for the Samba 3.4 project team I can confirm that we would like to pick option 1) now in order to be able to get Samba 3.4 to S10U9. Thanks, Lukas
