directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Moving DIRSHARED into DIRAPI, take 2
Date Tue, 24 Jan 2012 18:53:44 GMT
On 1/24/12 7:25 PM, Alex Karasulu wrote:
> On Tue, Jan 24, 2012 at 6:50 PM, Emmanuel Lecharny<>wrote:
>> On 1/24/12 5:25 PM, Alex Karasulu wrote:
>>> On Tue, Jan 24, 2012 at 3:47 PM, Pierre-Arnaud Marcelot<>*
>>> *wrote:
>>>   On 24 janv. 2012, at 14:33, Emmanuel Lecharny wrote:
>>>>   Hi guys,
>>>>> last summer, a [VOTE] has been started about merging DIRShARED with
>>>> DIRAPI. We have had 5 +1 votes for it, but the operation was not done,
>>>> because we didn't decide if API should be moved to SHARED or the
>>>> opposite.
>>>>   I have just the opposite view. DIRAPI should be merged into DIRSHARED
>>> but
>>> for now I suggest a hold. These are really trivial matters and we should
>>> not be inducing unnecessary turnover without a significant gain when we
>>> have two big branches of critical importance in motion.
>>> Can we just lay this to rest until mid-year this year and then have a full
>>> discussion about it?
>> Shared is a dead space right now. I really don't mind merging API into
>> shared, and killing API, except that for users, SHARED means absolutely
>> nothing, when API is the Jira project they will use for bugs they meet when
>> using the LDAP API. So IMHO, API is really more important than SHARED, even
>> if SHARED is potentially something we may want to keep around.
> With you on this and I can support both views myself. What I am trying to
> say is ... I agree with you on some of these points but similar arguments
> can be made in both directions just as well. Nothing screams out in either
> direction from the semantics point of view: so in the end this is just
> semantics.
> The important point is to preserve some of the historical investments made
> under these JIRA URLs and SVN paths. It's less disruptive and easier to
> merge API into SHARED than the other way around and technically the LDAP
> API is part of the code shared by both studio and apacheds.
> IMHO there are bigger fish we need to fry than this one, being at best a
> really minor issue. I'm weighing in on less disruption when no particular
> direction has an overwhelming benefit.

Ok, just to sumup :
- currently, when we release what we call 'shared' internally, we call 
it ldap-api on the web-site
- so now, our users are redirected to DIRAPI when it comes to fill a 
JIRA on shared
- that imply we have a SHARED JIRA space which is not any more used
- I think we should move the SHARED issues to API atm, in order to fix 
them, instead of forgetting them in the next release

Now, there are more to discuss :
- we should not just close SHARED, because it contain a lot of history. 
Merging SHARED into API could be a pb, mainly losing this history.
- DIRAPI is not necessarily a good name. It should be LDAP-API, imho
- currently, shared is used by Studio, Apacheds, and as a standalone 
LDAP API. I don't think we will change that sooner or later, and, for 
instance, creating a ldap-client-api and an ldap-server-api does not 
make any sense. But I don't think that in the long run, shared should be 
kept as a project name. I'd rather use ldap-api (but this is just me)

At the end, it's not urgent (except the issues migration). If everybody 
agrees about the opened issues migration to DIRAPI, I will be very fine. 
For any other modifications, I would be happy to reboot this discussion 
when we will be close to a RC, not during the milestones...

Is that ok ?

Emmanuel L├ęcharny

View raw message