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 Wed, 25 Jan 2012 00:49:56 GMT
On 1/24/12 9:29 PM, Alex Karasulu wrote:
> On Tue, Jan 24, 2012 at 8:53 PM, Emmanuel Lécharny<>wrote:
>> 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
>>>>>>>   DIRAPI. We have had 5 +1 votes for it, but the operation was
>>>>>> 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
>>>>> 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 ?
> Let me try to express some of my thoughts as best as I can. For some reason
> I've been unable to do it on this topic, maybe because I'm less interested
> in it than other matters.
> 1). We have three TLP subprojects which we release from subversion:
> One significant fact to note is that we release shared not directly but
> indirectly as a result to release studio or apacheds. Nevertheless we do
> need to perform proper releases out of shared in accordance with Apache
> guidelines.

Not any more. We also release the LDAP API separately. (in fact, it's 
not any different from shared)
> 2). Creating a new subproject like studio, apacheds or shared should really
> constitute a vote since it will have to go through the release process.
> We'll also have to make sure it's sustainable, meaning having 3 or so
> people that can actively work on it from different companies yada yada yada
> ...

I agree. We need a more diverse community.
> 3). When releasing we need to track and report the bugs fixed, the features
> added, and tasks completed with each release log. So for this reason it
> makes sense to have a JIRA project for each of these TLP subprojects:
> apacheds, shared, and studio.
> These are the reasons why non of the current recommendations sound optimal.
> So let's review the recommendation options:
> (a) keep both but move all issues even those in shared code base to the new
> LDAP-API project
> (b) merge SHARED into LDAP-API (or DIRAPI what have you)
> In option (a) there exists no TLP subproject code base for the LDAP-API and
> hence no code base for this JIRA Project: nothing  is being released yet
> issues are managed.
Not true : the LDAP API is released and has its own web site :

We don't have that for shared (except that shared == LdapAPI...)

> I understand there is a marketing reason for the name:
> the product name is the LDAP API which includes some of the code in shared.
> But this configuration is flawed based on what we release.
the LDAP API includes *all* the code in shared. It's just a different 
name. And yes, it's a better name, from the marketing POV. This is very 
clear. When we discussed about writing our own LDAP API (3 years ago) 
because JNDI sucked too much and because we needed a decent API to 
manage the replication, we decided to name it LDAP API, not shared.
> In option (b) we're talking about doing away with SHARED (deleting the JIRA
> Project) and just having an LDAP-API. This move then results in the SVN vs.
> JIRA discrepancy: the released code base is the shared subproject and jira
> calls it the ldap-api. Or we just rename the subproject in svn to ldap-api
> but then this is going to create unfold trouble for branches still working
> on shared branches.
>   There's a lot more fallout that I probably don't need
> to list which people can extrapolate.
this is clearly not a light decision. However, we don't have that many 
branches. Once those branches will be merged back to the trunk, we can 
then decide if we would like to rename shared to ldap-api (or whatever 
fits better).

We have plenty of time to discuss all the implication of such a choice, 
if we are going to select it.
> If we're to think about the release process and what we have today the best
> configuration is to just leave DIRSHARED and move the DIRAPI issues into it
> rather than succumbing to the marketing reasons for why users should go to
> an LDAP-API JIRA rather than DIRSHARED.
Clearly a big -1 to this proposal. People would be lost. Right now, 
nobody is filling issues in SHARED, they are using LDAP-API. Telling 
them to create issues is creating the risk that people will not know 
where to create a JIRA. Studio ? ApacheDS ?

IMO, Shared is and should remain an internal vision, not something we 
expose to the public. That it was created at the origin of the project 
does not make it a better name today. At the beginning, we didn't have a 
ldap API. This is not anymore the case.

> IMHO the API JIRA project should
> never have been created (a DIRSHARED label could have been used instead)
> and it was IMHO created as a result of overzealous project management
> activity. I might have been responsible for this but I don't really
> remember. It's now leading to more confusion over a relatively trivial
> matter which we can fix by dealing with the DIRSHARED name which has been
> there for ages and coincides well with our release process in line with our
> subversion configuration.
But DIRAPI is around for 3 years now, and IMO is fits way better to what 
we have. We should not stick to a 10 years old name which does not 
represent any more the reality of this part of the project.
Keep in mind that we have created this sub-project (well, at least, the 
web site, the ML and the JIRA, because the full LDAP-API code is just 
'shared') to be able to collaborate with the Sun peeps (and we have done 
quite a good progress when we were working together).
> The LDAP API is the product name and that can be respected, we can still
> make accommodations to have people use the DIRSHARED JIRA Project while
> pimping out an LDAP API. It's the least evil choice we have. The other
> options cause us more pain or just as much pain in different places in the
> end. Not everything needs to be ultra special having it's own JIRA.
I have a completely different opinion here. But we can disagree, it's 
not bad per se.
> In the end I'd rather not discuss this topic but move on to some really
> important things like reviewing some of the TxN work to understand it
> better and help. Or work on the OSGi branch to help with that. So I ask as
> a special favor of you all, let's just close this issue with this simple
> way for now and focus on the really important matters.
We can wait, put this question on standby until we get ready for a first 
RC. Then we will take all the needed time to discuss this, overall, 
minor issue.

The TxN layer and OSGi development are way way more important.

> Let's just delete
> the DIRAPI JIRA project and move everything back into DIRSHARED. This was
> the case for over half a decade until we all got excited about the LDAP
> API: me included. We even created a mailing list for it then abandoned it
> since things are best on user and dev lists.
The mailing list is still around. And it's now 3 years we have the LDAP 
API being actively developped and exposed on the web site as a separate 
project. I'm certainly not willing to kill -9 all that for the benefit 
of some historic name...
> In the big picture this is nothing at all.
I totally agree :) This is just a discussion, without any passion. No 
need to decide anything right now.

Feel free to comment, nobody will be stab in the back for expressing an 
opinion. At the end, when we will have fixed the main issues we are 
really facing (ie, TxN, OSGi), we will have time to decide and to vote.

Thanks !

Emmanuel Lécharny

View raw message