directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: DnNode class (was :Re: Creation of a second Subentry cache)
Date Mon, 03 Jan 2011 14:40:30 GMT
On Mon, Jan 3, 2011 at 2:07 PM, Emmanuel L├ęcharny <elecharny@apache.org>wrote:

> On 1/3/11 12:27 PM, Alex Karasulu wrote:
>
>> On Mon, Jan 3, 2011 at 10:55 AM, Emmanuel Lecharny<elecharny@gmail.com
>> >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<akarasulu@apache.org>
>>>>  wrote:
>>>>
>>>>  Not referring to the SchemaUI bundle. In studio we have all of ApacheDS
>>>>> available in the embedded ApacheDS plugin bundle. This however is not
>>>>> visible outside because it's an OSGi bundle, however there's no reason
>>>>> why
>>>>> the DnNode class cannot be accessed in a similar fashion through the
AP
>>>>> UI
>>>>> plugin bundle by having a dependency on core-api.
>>>>> Essentially studio already uses the entire server in the ApacheDS
>>>>> plugin.
>>>>>
>>>>>  It's not visible because the ApacheDS JARs are not added to the bundle
>>>> 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
>>>>
>>>>> managing
>>>>> APs?
>>>>>
>>>>>  Pierre-Arnaud already added this (and other) ApacheDS artifacts, so
>>>> they are available as OSGi bundles.
>>>>
>>>>  I have no problem moving DnNode class to core-API, except that it's
>>> 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.
>>
> 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.


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.


>
>  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.
>>
> Please, I don't need you to lecture me here.
>
>
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.


>
>  Bottom line, I don't really care, as soon as such moves are done when the
>>> 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
>>> release).
>>>
>>>  SVN allows you to merge code and work in parallel in a branch. No one
>> has to
>> wait for someone else to continue their work and merge.
>>
> No one has to make it painful for other, as you now perfectly well that
> tree conflicts are a PITA to handle.


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.


>
>  If you merge in first, I myself will deal with the cleanup involved on the
>> merge back after your AP changes.
>>
>
> This is why I told you it was not urgent.


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

<pmc-chair-hat-on>
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.
</pmc-chair-hat-on>

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.

After all this is a place to have fun.

Thanks,
-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message