directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?
Date Fri, 05 Aug 2011 11:24:57 GMT
On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot <>wrote:

> On 5 juil. 2011, at 22:53, Alex Karasulu wrote:
> > On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <>
> wrote:
> >> On 7/5/11 11:47 AM, Pierre-Arnaud Marcelot wrote:
> >>>
> >>> Just to be clear before I make the changes.
> >>>
> >>> Should I merge DIRSHARED into DIRAPI ? or DIRAPI into DIRSHARED?
> >>>
> >>> My choice would be the first option, as Shared is becoming the API.
> >>> What's yours?
> >>
> >> DIRAPI is way better, IMHO.
> >
> > I suggest the opposite because of the investment that has gone into
> > references for DIRSHARED. And at the end of the day it's still shared
> > stuff across both main projects, studio and the server. There are more
> > things that will go into this down the line besides LDAP. If we
> > release later we can release just parts of it instead of the whole
> > thing: meaning just the ldap api.
> >
> > We can still restructure but we're going to unsettle some references
> > we've put even into the code around these issues from the past. If
> > you're find with doing away with it then I can live with it but we
> > will lose more.
> Hi Alex,
> I understand your point but hopefully JIRA is pretty well built and manages
> to keep references perfectly.
No arguments there. Jira is just great.

> Have a look a recent issue a user created in a wrong JIRA project,
> It has been created in the DIRSERVER project but I moved it later to
> DIRAPI, since the issue was related to the LDAP API instead.
> During the move of the issue JIRA gave a new ID to the issue in the DIRAPI
> project, DIRAPI-47.
> The old ID is still valid and the JIRA link
> now redirects to the
> new issue:
> Lastly, in the Activity section of the issue ('All' sub-section selected),
> the move has been registered with both origin and destination values
> (project, version).
> So, as you see, I'm not really sure we're going to loose anything in the
> migration...
Yeah I see this np. However my worry is in labeling this Directory TOP level
project as specific to the LDAP API since we're most likely going to have
more protocol API's added in the not so distant future. However if you guys
are thinking of creating yet another project that is a peer of DIRAPI say
DIRKRBAPI, then this might be possible but then we need to be a little more
explicit. Perhaps then DIRLDAPAPI so we can have DIRKRBAPI etc. See where I
am going?

However I may be over doing it with the categorization. I am just stating
that we should just do this once and not have to deal with such a shift
again in the next year when this new API emerges naturally out of our
progress. Just trying to hint at some way to save us all some more
management overhead otherwise it's a no brainer.

> The only thing we'd probably want to do is to create new versions in the
> DIRAPI project matching all versions of the DIRSHARED project.
> Maybe with a prefix, to avoid any misunderstanding.
> 0.9.19 in the DIRSHARED project would then become shared-0.9.19 in the
> DIRAPI project.
This seems to be getting more involved in terms of managing things. Renaming
things is not really going to add all that much value, but it will mix up or
organization changing links that are embedded in certain places referencing
issues. There's probably a better way I just want a bit more thought on it
because really there's no serious urgency or am I missing something here?

Best Regards,
-- Alex

View raw message