On Tue, Jan 24, 2012 at 8:53 PM, Emmanuel Lécharny <elecha...@apache.org>wrote:
> On 1/24/12 7:25 PM, Alex Karasulu wrote: > >> On Tue, Jan 24, 2012 at 6:50 PM, Emmanuel Lecharny<elecha...@gmail.com>** >> wrote: >> >> On 1/24/12 5:25 PM, Alex Karasulu wrote: >>> >>> On Tue, Jan 24, 2012 at 3:47 PM, Pierre-Arnaud Marcelot<p...@marcelot.net >>>> >* >>>> *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 ? > > 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: https://svn.apache.org/repos/asf/directory/shared https://svn.apache.org/repos/asf/directory/studio https://svn.apache.org/repos/asf/directory/apacheds 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. 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 ... 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. 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. 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. 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. 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. 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. 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. 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. In the big picture this is nothing at all. -- Best Regards, -- Alex
