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 16:06:16 GMT
On Fri, Aug 5, 2011 at 4:55 PM, Pierre-Arnaud Marcelot <>wrote:

> On 5 août 2011, at 15:17, Alex Karasulu wrote:
> On Fri, Aug 5, 2011 at 3:24 PM, Pierre-Arnaud Marcelot <>wrote:
>> On 5 août 2011, at 13:24, Alex Karasulu wrote:
>> 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,
>>> DIRSERVER-1630.
>>> 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?
>> Yeah, but I can't foresee the future.
> Nor can I but when in doubt, without an immediate need or urgency it's best
> not to act. I'm really not seeing this as anything more than just renaming
> something to rename it. I think as a group we need to avoid such things as
> we stabilize both in terms of our products, their documentation and our
> habits. I advocated more gitter in the past to help us find the best resting
> points early when we were forming but now we need to be a bit more
> conservative with some gitter in the right place. This move just does not
> have value, and it churns things needlessly. Why do it?
> As I already explained, the current situation isn't sane since we have two
> different Jira projects associated to a single "code project".
> From a developer POV it forces us to maintain versions in both projects and
> makes it difficult to maintain a clear roadmap and/or release notes for each
> version.
> From a users POV, it is confusing and users report issues in both projects.
> It depends on how we organize the project (in terms of version control,
>> build and release).
>> We could have a single project (the current DIRAPI project for example)
>> and multiple components in it: ldap, kerberos.
>> Or we could have two different projects instead...
> Yep agreed.
> The whole change here is between API and SHARED. Not everything is API
> related either. It could just have been called COMMON.
> I thought we had all agreed that the current 'shared' sub-project is
> actually what we call the API.

I don't agree with this, hence why I am responding to this thread.

> If there are things in it that are not API related, then we need to create
> a separate 'api' trunk and move all API-related code to this new trunk,
> while leaving the common (shared) code in the 'shared' trunk.
> In that case, maybe the merge of JIRA projects should not happen.
> If we have and/or if we are going to have in a very near future (one year
> or less) some code (probably common to a number of projects) which is not
> released as part of the API, then we should probably keep DIRSHARED as is
> and dedicate DIRAPI to the specific API releases.
That's another option.

> The only thing that bugs me currently is that we have two Jira projects for
> a single "code project" and we should remedy it.
>  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.
>> It is not mandatory, just a thought I had to maintain some kind of basic
>> history (for the moved items).
>> Links to the moved issues will continue to work with both forms (old and
>> new project ID), as I explained above.
>> 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?
>> There's no "real" urgency but it has to be done because it has already
>> been voted
> We started a vote but we're still discussing this. I just want to get on
> base community wise on this and make all the necessary points. Really it's
> not going to kill us making this move but it's that we are continuously
> making these kinds of changes. Our users are going to get confused
> additively over time.
> That's exactly why I launched the discussion and I'm waiting that we all
> agree on the correct change before doing anything.
> Consensus and community is the key...

Bravo ... thanks for that.


View raw message