On Fri, Aug 5, 2011 at 4:55 PM, Pierre-Arnaud Marcelot <[email protected]>wrote:
> On 5 août 2011, at 15:17, Alex Karasulu wrote: > > On Fri, Aug 5, 2011 at 3:24 PM, Pierre-Arnaud Marcelot > <[email protected]>wrote: > >> On 5 août 2011, at 13:24, Alex Karasulu wrote: >> >> On Wed, Jul 6, 2011 at 10:19 AM, Pierre-Arnaud Marcelot >> <[email protected]>wrote: >> >>> On 5 juil. 2011, at 22:53, Alex Karasulu wrote: >>> >>> > On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny <[email protected]> >>> 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
