On Mon, Jan 3, 2011 at 2:07 PM, Emmanuel Lécharny <email@example.com>
I still believe that there is no valid technical reason for this move. I still believe that we will need this class on the client side, without having to depend on core-api.
On 1/3/11 12:27 PM, Alex Karasulu wrote:
On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharny<firstname.lastname@example.org>wrote:
(Renamed the thread for clarity)
On 1/3/11 9:40 AM, Stefan Seelmann wrote:
On Mon, Jan 3, 2011 at 2:27 AM, Alex Karasulu<email@example.com>
I have no problem moving DnNode class to core-API, except that it's
Not referring to the SchemaUI bundle. In studio we have all of ApacheDS
It's not visible because the ApacheDS JARs are not added to the bundle
available in the embedded ApacheDS plugin bundle. This however is not
visible outside because it's an OSGi bundle, however there's no reason
the DnNode class cannot be accessed in a similar fashion through the AP
plugin bundle by having a dependency on core-api.
Essentially studio already uses the entire server in the ApacheDS plugin.
classpath. Instead the ApacheDS plugin just extracts the entire server
to the file system and starts a new java process.
What's the big deal in having another bundle depend on core-api for
Pierre-Arnaud already added this (and other) ApacheDS artifacts, so
they are available as OSGi bundles.
probably not the right timing to do so.
Well you've been incredibly reticent especially while I provided valid
strong points for the move. So saying no problem seems very contradictory.
Beliefs are not good enough, you need to support your points with technical facts. I was going to make this move in my branch but I thought I'd discuss it with the community. My doing so is a matter of respect and congeniality towards the community.
I can if you like supply the technical points once again and we can review each one. This is not a pissing contest for me it's PURELY technical. It's about properly managing the shared API and releasing a 1.0 so we can then get to work on ApacheDS 2.0.
I just have no problem getting this class moved around as soon as it's present somewhere. If we have to move it back to shared later, so be it. I won't block anything in this area because it's not relevant. As you said, my personal feelings are not important.
If I did not respect your feelings I would not have opened this up for discussion even though the technical reasoning behind the move is valid. If I did not care I would have just moved it.
This drawn out conversation is just a pure waste of time but you're the one pushing it and I am politely listening and supplying the technical information needed to make the right choice. I will never loose patience with you but please stick to the facts.
The truth and the technical facts will always lead to resolution.
Please, I don't need you to lecture me here.
Plus I'm not using my feelings, opinions or saying probably here. I sited
some valid technical arguments and that's how we operate here in Apache.
You brought it upon yourself. Stick to the technical facts and stop filibustering with feelings, beliefs and opinions. If you stopped pushing back with comments that have no way to be rationally discussed and stuck to technical points I would not have to point out your not supplying technical points.
You leave me with no other option but to point out what a person is doing when someone tells me, "but I feel this is better," repeatedly without supplying technical reasons or challenging the ones I have presented? If you give me other options I will gladly and respectfully consider them.
Let's not waste our time.
No one has to make it painful for other, as you now perfectly well that tree conflicts are a PITA to handle.
Bottom line, I don't really care, as soon as such moves are done when the
SVN allows you to merge code and work in parallel in a branch. No one has to
current work done on AP are completed, in order to ease the merge back to
trunk (other wise it will be a nightmare), plus as soon as we check the
impact of such moves on studio (and here, i'm not talking about DnNode, but
about other potential changes we will have to do in shared before the
wait for someone else to continue their work and merge.
There's no reason why I have to stop my activity to facilitate yours. We should be able to work in parallel. But most important of all there are no by laws stating this in the foundation.
However if you don't want to handle a merge I can see about waiting for you and deal with the conflict resolution myself. That is if you don't take too long.
More than that, we already discussed this point earlier : changing shared is anything but urgent atm.
Urgent or not this is your characterization and opinion.
I'm a member of an open source community working on a project and code base I love and started working on over 10 years ago. Unless technically unsound there's no reason why I have to be dictated to about how to participate. No member of the community needs to feel this kind of pressure.
I'm working on shared because I'm enjoying cleaning up the years of disorder there and getting it ready. I feel no urgency either - this is just my preference and my right.
There is no serious issues in it, and once the last blocking issue in the server, namely the AP handling, is fixed, then as I said, we can start and cleanup shared.
That's not up to you to dictate. This is not a company where I am mandated to work on what someone tells me to work on. Again if there are technical issues that's a another matter. I'm always open to being shown a better way. Ownership of the idea is not important to me, doing it right is.
If you want to help us to fix this AP thing, you are more than welcome.
I was going to and really looking forward to working with you on this but when I started discussing it with you I was confronted by a very subtle negativity. You ask me to help then when I start working with you, you give me a kind of passive aggressive attitude. If you like we can discuss this off list. It's getting frustrating so I chose to keep a distance. I volunteered my points and left it up to you. There is nothing else I can do. I'm just trying to be rational and non-confrontational with you.
This no brainer issue with the DnNode move is one example and we wasted a lot of time unnecessarily discussing it. I provided clear points which you have yet to refute. If you don't have anything further to add then I will continue the move in my branch isolated from you so it does not disrupt you. I can also yield so you merge first and handle conflicts myself. No problem for me.
This is why I told you it was not urgent.
If you merge in first, I myself will deal with the cleanup involved on the
merge back after your AP changes.
Again this is your interpretation and I feel no urgency. I'm just working on my hobby.
People are working on trunk, I do merge back the fixes that are injected into trunk tothe AP branch in order to avoid such conflicts later. Shared modifications you are currently doing are not entering this area because it's not urgent.
Again that's your interpretation - you're acting like you're in charge and that's not good. There is no central authority here. Communities will stop growing if people are going to be pressured needlessly especially after they've invested so much love into projects here at the ASF.
We already had a discussion back in october about Shared refactoring, a lot of modifications have been made back then, and I don't remember having seen any objection from you back then.
I followed all those discussions and very good progress was made at that time. There was a lot of consolidation that I was always recommending in the past but had no time for. Kudos to those who took up the effort. It was a job well done but there's more to be done unfortunately.
Also at that time I did not have the wattage to inspect every change. I was dealing with a divorce, depression, and I lost my job. I was really down. Now I have some time and morale to comb through the state of the shared libraries and this is what I'm doing. If you're angry about that I don't know what I can to help you ease up.
I find it a bit strange to see you pushing as much as you can for minor modifications that are not urgent not necessary.
You can speculate as much as you like and down play my contributions. That's your opinion again. But with my
It's best we avoid these kinds of negative speculatory comments which never end once begun. Sticking to the technical details is best for us all.
There's nothing wrong with asking one member to yield to another for a merge but that's at the discretion of individuals, and not something mandated by any project's guidelines or the bylaws of the foundation.
As a committer and member of this community I'm having fun working on something I love. That should not ever become an issue for anyone unless person is doing something wrong technically and inhibiting the community. I'm always ready and willing to discuss my technical mistakes in a polite and cordial manner.