[VOTE] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Having done some cleaning in both JIRA spaces this morning, I'm really wondering if those two shouldn't be merged.

Please cast your votes:
[ ] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA
[ ]  0 - Abstain
[ ] -1 - Do NOT merge the DIRSHARED and DIRAPI spaces in JIRA

Regards,
Pierre-Arnaud

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Emmanuel Lécharny <el...@apache.org>]

On 7/5/11 10:53 PM, Alex Karasulu wrote:
> On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny<el...@gmail.com>  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.
I agree for the 'investment', except that it's just a name. From now on, 
the API is what we use in Studio and the server. There is not much we 
don't expose as a generic LDAP API in shared (only what is specific to 
the server, like the triggers and SP).
> 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.
That's an option. Most of what is currently Shared is in fact the LDAP 
API. An extra effort could split shared in two parts : the LDAP API 
(most of what is shared atm) and what is specific to the server. It 
would probably worth the effort.
> 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.
Can you give some exemple ?

>   If
> you're find with doing away with it then I can live with it but we
> will lose more.
We still are in Milestone mode, so there is no need to freeze anything 
here. Having the API being adopted more and more will however lead us to 
expose it as what it is : a replacement for JNDI. Naming it shared is at 
this point misleading. I think this is the rational behind this proposal.

But that does not mean we should not have a new suproject which contains 
what is not part of the LDAP api.



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Dev,

Digging out this one month old unresolved thread.

I'd prefer getting everyone's +1 before performing the move.

What's your take on this?

Regards,
Pierre-Arnaud

On 6 juil. 2011, at 09:19, 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 <el...@gmail.com> 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.
> 
> 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 https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to the new issue:
> https://issues.apache.org/jira/browse/DIRAPI-47
> 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...
> 
> 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.
> 
> Thoughts?
> 
> Regards,
> Pierre-Arnaud
> 
>> Regards,
>> Alex
> 

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Alex Karasulu <ak...@apache.org>]

On Fri, Aug 5, 2011 at 4:55 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:

> On 5 août 2011, at 15:17, Alex Karasulu wrote:
>
> On Fri, Aug 5, 2011 at 3:24 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:
>
>> On 5 août 2011, at 13:24, Alex Karasulu wrote:
>>
>> On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:
>>
>>> On 5 juil. 2011, at 22:53, Alex Karasulu wrote:
>>>
>>> > On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <el...@gmail.com>
>>> 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
>>> https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to
>>> the new issue:
>>> https://issues.apache.org/jira/browse/DIRAPI-47
>>> 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.

Regards,
Alex

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

I quickly read the discussion, and at this point, I don't see an urgency 
to change things.

I mean, I think we should have DIR-SHARED *or* DIR-API, but not both, 
except that right now, we haven't released the 1.0.0-RC1, the API doco 
is frankly in its infancy, so let's not push to hard on something which 
is relatively minor.

When I see questions like 'is the API stable enough', I'm just telling 
myself 'guy, we'd better move to a RC1 fast before playing around with 
names...'

Let's abot this thread right now, and move on. We will be back with this 
question later.


On 8/5/11 3: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<pa...@marcelot.net>  wrote:
>> On 5 août 2011, at 13:24, Alex Karasulu wrote:
>>
>>> On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot<pa...@marcelot.net>  wrote:
>>> On 5 juil. 2011, at 22:53, Alex Karasulu wrote:
>>>
>>>> On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny<el...@gmail.com>  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 https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to the new issue:
>>> https://issues.apache.org/jira/browse/DIRAPI-47
>>> 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.
> 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.
>
> 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...
>
> Regards,
> Pierre-Arnaud
>
>> and more importantly because it is really confusing to have two JIRA projects associated with a single project.
>>
>> There's more issues inside the DIRAPI than in DIRSHARED plus DIRAPI is less commonly used since DIRSHARED has been around so much more. This is my whole point in that if we need to push a merge let's do it by merging DIRAPI since there's less investment in it. Plus the API concept holds less than the SHARED and COMMON concepts do. All the code in this area is not just for exposing an API. It's for code that is common across our major products: Studio and ApacheDS.
>>
>> People are contributing bug and improvement reports in both projects and it's getting complicated to merge things when doing a release because you have to look at two spaces.
>> It also involves managing versions for the two projects, etc. etc...
>>
>>
>> Understood. So then a merge is valid and I'm not disputing this at all. These are very good reasons to merge these however let's give up on the Jira project we have the least time and effort investment in both as committers and as users.
>>
>> That was the whole point of the initial vote...
>>
>>
>> I totally agree with you, so the question now is what stays and what is merged away. My arithmetic on this matter deals with investment time and what identifier best fits our way of managing and releasing projects.
>>
>> So I'm a +1 on the merger. A +1 on merging DIRAPI into DIRSHARED where DIRAPI disappears and a -1 on the reverse due to the reasons I stated above. Please excuse me for beating a dead horse to death on this matter but I sincerely feel that we have significant investment in DIRSHARED over DIRAPI over time, energy and community familiarity.
>>
>> Best Regards,
>> -- Alex
>>
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

On 5 août 2011, at 15:17, Alex Karasulu wrote:
> On Fri, Aug 5, 2011 at 3:24 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> On 5 août 2011, at 13:24, Alex Karasulu wrote:
> 
>> On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
>> On 5 juil. 2011, at 22:53, Alex Karasulu wrote:
>> 
>> > On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <el...@gmail.com> 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 https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to the new issue:
>> https://issues.apache.org/jira/browse/DIRAPI-47
>> 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.
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.

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...

Regards,
Pierre-Arnaud

> and more importantly because it is really confusing to have two JIRA projects associated with a single project.
> 
> There's more issues inside the DIRAPI than in DIRSHARED plus DIRAPI is less commonly used since DIRSHARED has been around so much more. This is my whole point in that if we need to push a merge let's do it by merging DIRAPI since there's less investment in it. Plus the API concept holds less than the SHARED and COMMON concepts do. All the code in this area is not just for exposing an API. It's for code that is common across our major products: Studio and ApacheDS.
>  
> People are contributing bug and improvement reports in both projects and it's getting complicated to merge things when doing a release because you have to look at two spaces.
> It also involves managing versions for the two projects, etc. etc...
> 
> 
> Understood. So then a merge is valid and I'm not disputing this at all. These are very good reasons to merge these however let's give up on the Jira project we have the least time and effort investment in both as committers and as users.
>  
> That was the whole point of the initial vote...
> 
> 
> I totally agree with you, so the question now is what stays and what is merged away. My arithmetic on this matter deals with investment time and what identifier best fits our way of managing and releasing projects. 
> 
> So I'm a +1 on the merger. A +1 on merging DIRAPI into DIRSHARED where DIRAPI disappears and a -1 on the reverse due to the reasons I stated above. Please excuse me for beating a dead horse to death on this matter but I sincerely feel that we have significant investment in DIRSHARED over DIRAPI over time, energy and community familiarity.
> 
> Best Regards,
> -- Alex
> 

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Alex Karasulu <ak...@apache.org>]

On Fri, Aug 5, 2011 at 3:24 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:

> On 5 août 2011, at 13:24, Alex Karasulu wrote:
>
> On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:
>
>> On 5 juil. 2011, at 22:53, Alex Karasulu wrote:
>>
>> > On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <el...@gmail.com>
>> 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
>> https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to the
>> new issue:
>> https://issues.apache.org/jira/browse/DIRAPI-47
>> 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?


> 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.


> 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.


> and more importantly because it is really confusing to have two JIRA
> projects associated with a single project.
>

There's more issues inside the DIRAPI than in DIRSHARED plus DIRAPI is less
commonly used since DIRSHARED has been around so much more. This is my whole
point in that if we need to push a merge let's do it by merging DIRAPI since
there's less investment in it. Plus the API concept holds less than the
SHARED and COMMON concepts do. All the code in this area is not just for
exposing an API. It's for code that is common across our major products:
Studio and ApacheDS.


> People are contributing bug and improvement reports in both projects and
> it's getting complicated to merge things when doing a release because you
> have to look at two spaces.
> It also involves managing versions for the two projects, etc. etc...
>
>
Understood. So then a merge is valid and I'm not disputing this at all.
These are very good reasons to merge these however let's give up on the Jira
project we have the least time and effort investment in both as committers
and as users.


> That was the whole point of the initial vote...
>
>
I totally agree with you, so the question now is what stays and what is
merged away. My arithmetic on this matter deals with investment time and
what identifier best fits our way of managing and releasing projects.

So I'm a +1 on the merger. A +1 on merging DIRAPI into DIRSHARED where
DIRAPI disappears and a -1 on the reverse due to the reasons I stated
above. Please excuse me for beating a dead horse to death on this matter but
I sincerely feel that we have significant investment in DIRSHARED over
DIRAPI over time, energy and community familiarity.

Best Regards,
-- Alex

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

On 5 août 2011, at 13:24, Alex Karasulu wrote:

> On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> On 5 juil. 2011, at 22:53, Alex Karasulu wrote:
> 
> > On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <el...@gmail.com> 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 https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to the new issue:
> https://issues.apache.org/jira/browse/DIRAPI-47
> 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.

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...

> 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 and more importantly because it is really confusing to have two JIRA projects associated with a single project.
People are contributing bug and improvement reports in both projects and it's getting complicated to merge things when doing a release because you have to look at two spaces.
It also involves managing versions for the two projects, etc. etc...

That was the whole point of the initial vote...

Regards,
Pierre-Arnaud

> -- 
> Best Regards,
> -- Alex
> 

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Alex Karasulu <ak...@apache.org>]

On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:

> On 5 juil. 2011, at 22:53, Alex Karasulu wrote:
>
> > On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <el...@gmail.com>
> 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
> https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to the
> new issue:
> https://issues.apache.org/jira/browse/DIRAPI-47
> 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

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

On 5 juil. 2011, at 22:53, Alex Karasulu wrote:

> On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <el...@gmail.com> 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.

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 https://issues.apache.org/jira/browse/DIRSERVER-1630 now redirects to the new issue:
https://issues.apache.org/jira/browse/DIRAPI-47
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...

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.

Thoughts?

Regards,
Pierre-Arnaud

> Regards,
> Alex

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Alex Karasulu <ak...@apache.org>]

On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <el...@gmail.com> 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.

Regards,
Alex

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Emmanuel Lecharny <el...@gmail.com>]

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.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

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?

Regards,
Pierre-Arnaud


On 5 juil. 2011, at 09:24, Pierre-Arnaud Marcelot wrote:

> This vote is now closed.
> 
> Here are the results:
> 5 +1 votes:
>  - Kiran Ayyagari
>  - Alex Karasulu
>  - Emmanuel Lécharny
>  - Felix Knecht
>  - Pierre-Arnaud Marcelot
> No ±0 and -1 votes
> 
> I'm going to merge the two JIRA spaces today.
> 
> Thanks!
> Pierre-Arnaud
> 
> On 1 juil. 2011, at 13:13, Pierre-Arnaud Marcelot wrote:
> 
>> Having done some cleaning in both JIRA spaces this morning, I'm really wondering if those two shouldn't be merged.
>> 
>> Please cast your votes:
>> [ ] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA
>> [ ]  0 - Abstain
>> [ ] -1 - Do NOT merge the DIRSHARED and DIRAPI spaces in JIRA
>> 
>> Regards,
>> Pierre-Arnaud
> 

[VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

This vote is now closed.

Here are the results:
5 +1 votes:
  - Kiran Ayyagari
  - Alex Karasulu
  - Emmanuel Lécharny
  - Felix Knecht
  - Pierre-Arnaud Marcelot
No ±0 and -1 votes

I'm going to merge the two JIRA spaces today.

Thanks!
Pierre-Arnaud

On 1 juil. 2011, at 13:13, Pierre-Arnaud Marcelot wrote:

> Having done some cleaning in both JIRA spaces this morning, I'm really wondering if those two shouldn't be merged.
> 
> Please cast your votes:
> [ ] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA
> [ ]  0 - Abstain
> [ ] -1 - Do NOT merge the DIRSHARED and DIRAPI spaces in JIRA
> 
> Regards,
> Pierre-Arnaud

Re: [VOTE] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Felix Knecht <fe...@apache.org>]

> [X] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA

Avoid the disorder of having a JIRA space and no project.

Regards
Felix

Re: [VOTE] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Emmanuel Lecharny <el...@gmail.com>]

On 7/1/11 1:13 PM, Pierre-Arnaud Marcelot wrote:
> Having done some cleaning in both JIRA spaces this morning, I'm really wondering if those two shouldn't be merged.
>
> Please cast your votes:
> [X] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA

Definitively needed.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [VOTE] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

[X] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA

Regards,
Pierre-Arnaud


On 1 juil. 2011, at 13:13, Pierre-Arnaud Marcelot wrote:

> Having done some cleaning in both JIRA spaces this morning, I'm really wondering if those two shouldn't be merged.
> 
> Please cast your votes:
> [ ] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA
> [ ]  0 - Abstain
> [ ] -1 - Do NOT merge the DIRSHARED and DIRAPI spaces in JIRA
> 
> Regards,
> Pierre-Arnaud

Re: [VOTE] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Kiran Ayyagari <ka...@apache.org>]

+1, merge DIRSHARED and DIRAPI spaces, makes sense to me

On Fri, Jul 1, 2011 at 4:43 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Having done some cleaning in both JIRA spaces this morning, I'm really wondering if those two shouldn't be merged.
>
> Please cast your votes:
> [ ] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA
> [ ]  0 - Abstain
> [ ] -1 - Do NOT merge the DIRSHARED and DIRAPI spaces in JIRA
>
> Regards,
> Pierre-Arnaud



-- 
Kiran Ayyagari

Re: [VOTE] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?

[Alex Karasulu <ak...@apache.org>]

On Fri, Jul 1, 2011 at 2:13 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Having done some cleaning in both JIRA spaces this morning, I'm really wondering if those two shouldn't be merged.
>
> Please cast your votes:
> [X] +1 - Merge the DIRSHARED and DIRAPI spaces in JIRA