David,
I would like to publicly apologize for my behavior this past weekend.
While I do not believe you (or anyone else) has the right to revert
any commit which does not directly effect the build or ability to run
the trunk without first discussing with the author and giving them a
chance to correct/revert the changes themselves; I also do not believe
I should have responded to you the way I did. For that I wish to offer
you my sincerest apology.
I do not believe your actions were a direct attack on me personally, I
responded abruptly in the heat of the moment. Having worked together
on OFBiz for the last 8 years we both should have been able to rectify
any differences without offending one another. Again, I apologize or
not acting appropriately.
Andrew
On May 3, 2009, at 4:00 PM, Andrew Zeneski wrote:
Inline...
Please don't revert the rest of the code. The point is that this
needs time to mature, so it should stay in there but not become the
default... not YET anyway.
I will leave the what was implemented alone for the time being.
Also, please don't be personally offended by this. Just because
there are comments and feedback doesn't mean something has no
merit, it just means that some adjustments to it might be able to
improve it. That's what collaboration is all about, and I guess if
you'd rather not do it than have other people comments on it and
make changes to it then collaboration will be difficult.
I am not offended by any comments or feedback, I was only offended
by your actions. Reverting the example was nothing more than a power
move by you. You can argue this if you wish, but the fact is nothing
else except for an example was effected, and there has been no
discussion by anyone to revert anything yet. If you did feel that it
was problematic, it should have been brought up if not to the
community then at least to me personally.
Just to clear that up... are you saying you would rather not do any
of this than make some changes and refinements to it based on
feedback? I hope that's not the case. My intent with this, as I
explained in my email, is to make a compromise and allow
development and improvement on this to continue without impact on
other parts of the project until it is more ready for that.
Your assumptions (as assumptions often are) completely wrong. Even
though say now you hope this isn't the case, you have publicly
accused me of this in your Notes On Security Changes document. What
have I been doing for the past week? It surely wasn't moving ahead
and checking in changes to all the applications to use a new
authorization pattern. What I have been doing is acquiring
additional needs/requirements comparing them to what I have planned
and trying to discuss with the community these changes. Refining the
API and including the requirements which I have gathered.
You keep claiming that this new pattern is less flexible. While that
may (but I don't agree) be true to a certain extent, is it also far
MORE flexible when it comes to creating custom implementations for
vertical, custom or customized applications.
Andrew
