Hi Leo: Leo Simons wrote:
Dear all, as most of you are probably at least dimly aware, there exists bad blood between the committers mentioned in the subject line. This has (publicly) been clear ever since the 'meta model wars', and has more recently been subject of debate (I'd personally call it mudslinging, even if not so intended) within several new mailing lists, including reorg@apache, general@commons and incubator@apache.
I appreciate you taking the time to bring this up. I honestly don't think there is specific thing that one can point at and say "that was the cause". It something that has been growing since April.
However, based on the recent series of attacks, I can make some assumptions about the issue that Pete has. Starting with the most recent ...
06-NOV-2002, incubator list: Peter Donald wrote:
> The best I have seen so far is a committer forking a project so he
> can add his name as an @author - would have been funny except that
> it effectively blocked progress in that project.
I think anyone who was on this list in July will remember the discussion on containerkit and recognize the absurdity of the above statement. One of the questions asked by Greg Stein over on the incubator list was "what was the reason for the fork" (an earlier email I posted only addressed the differences). For those interested in looking into the history leading up the establishment of the excalibur/meta package will find a wealth of information in the following thread.
http://marc.theaimsgroup.com/?t=102558313100001&r=1&w=2
Or a short form summary that you prepared at the time:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102611426519091&w=2
The fork became necessary because I could not use containerkit in my work, and Pete made it totally clear that he was not going to allow the changes that I proposed. He made this clear both in his response on list and even more clearly in off-list emails.
The result was the application of a revolution and the creation of the much smaller sub-package within excalibur/assembly on 5 July. After some revision incorporating improvements to method names, class naming, and substantial documentation enhancements, the package was separated out in excalibur/meta on August 20 as part of the collaboration with the Fortress project.
I think Pete considers that the excalibur/meta package is simply a rip-off of his work. In some respects he dead right - in other respects he is dead-wrong. Yes - it remains very close to his original design and in that respect I think this reflects the quality of his work. The package is however a revolution as and such work has proceeded without problem. This includes the addition of meta structures supporting the Fortress/Merlin extension model and progressive refinements to the code and documentation.
I think it's also a safe bet that Pete has a problem with the fact that I have included my name as an author along side Pete. An important point from my own perspective is that someone reading the code can get my email address if they want to ask questions off-list. However, to really understand the issue - we would need some feedback from Pete.
In follow-up emails on the incubator list - Pete alluded to reverting vetoed changes. Presumably this all relates to the problems that broke out at and around the 16, 17 and 18 August.
1. the Cornerstone Context interface issue
2. the BlockContext and GenericBlockContext sarga
3. the Cornerstone .xtype and .xprofile issue
4. the repackaging of containerkit under the framework namespace
The context to (1), (2) and (3) was related to the testing of the Merlin platform with the CVS version of James and Cornerstone.
The Cornerstone Context interface issue
---------------------------------------
These test identified problems concerning the changes introduced by the retraction of the Block interface. In effect, the Cornerstone components are a released set of components that implemented the Component interface. However, the inclusion of Component was somewhat hidden in that it is a super-type of Block. Retracting Block resulted in the retraction of Component. The issue raised was that the retraction of Component resulted in class cast exceptions when attempting to use Cornerstone components within the Avalon framework DefaultComponentManager (or other simple implementations of the Composable interface). Irrespective of proxied solutions available in different containers, I argued that the Component interface should remain so as to ensure backward compatibility. While the public discussion on this seems to reach the same conclusion, the codebase remains unchanged. In general - this does not bother me too much because I have the impression that Cornerstone component usage is limited and that backward incompatibility issue is manageable because the number of occurrences of use outside of Phoenix is approaching a very small number. However, it is a case that demonstrates insufficient management of Cornerstone release processes.
The BlockContext and GenericBlockContext sarga
----------------------------------------------
This issue was more complex and more subtle. The GenericBlockContext class was a small utility class that any container could use to work around Phoenix specific dependencies that exist within the Cornerstone codebase. On one hand, Avalon advertises itself as a component framework and a set of reusable components, but on the other-hand, Cornerstone components are tied to Phoenix due to the introduction of the BlockContext interface. After committing the source midday on the 17 August, it was removed from the CVS by Pete about 14 hours later with the CVS commit message "Revert changes that were -1'ed.". I recommitted the file and posted an email requesting justification. I think also expressed my doubts about the validity of the veto and requested and explanation. Unfortunately Pete was in -1 mode and I think in total I was hit with at least 6 or 7 vetos in one day - nothing approaching a constructive dialog let alone any discussion.
The Cornerstone .xtype and .xprofile issue
------------------------------------------
The particular issue concerned the introduction of a set of supporting meta-data files into the Cornerstone packages enabling the transparent deployment of Cornerstone components within the Merlin 2 container. In all cases the files in question represented zero conflict with existing resources, ensured that all components could be easily deployed in both Merlin and Phoenix. The addition of files was veto by Pete on the grounds that the meta information used in Phoenix was sufficient, and secondly, he claimed he had plans concerning the use of a file named <classname>.xprofile and apparently he believed that he had a prior right to use this. At this point my appreciation for Pete and the credibility of his vetos fell to an all time low.
The repackaging of containerkit under the framework namespace
-------------------------------------------------------------
On the 18 August quietly and without prior dev discussion - Pete moved the meta-info structures in containerkit from the org.apche.excalibur.containerkit package in the org.apache.avalon.framework package namespace. I objected to this on the grounds that it implied an endorsement of this as framework content and requested that the package be renamed. This was expressed under a veto from me to Pete (I was learning to play using Peter's model of collaborative development). Pete ignored the veto and the package still remains under the framework namespace.
I have spent some time talking to both offline trying to figure out where the problems lie and how they could be fixed in some way that would be agreeable to both. I can't really see how. I am also still unsure where the root of the problem lies.
I find it very difficult to believe that the interventions from Pete are driven on any technical rationale. That makes is somewhat difficult to isolate the problem.
The impression I have of where things are going now is that Peter will reduce his involvement in avalon, probably moving the stuff he is involved in to other projects if applicable, or off of apache if not. I also believe Stephen is aiming for modification of stuff like voting guidelines @ avalon, setting up an avalon PMC etc. I think he believes this will make problems like have arisen between him and Pete not occur in the future, or to less an extend.
Let me clarify something here. I do believe that the level of responsibility we engage into concerning Avalon is an important factor. Yes, I would like to see Avalon escalate to a top level project - I would like to see the formation of a PMC that is answerable to the Board. I would like to see more product focus - something that I think can be achieved through restructuring ... things like establishing and documenting our mission/scope/etc. On the point concerning guidelines - I don't see that as something Avalon specific - this is much more something I would like to see coming up through the incubator project. In that respect I'm glad to see that the Pete/Steve conflict is being reviewed in detail and I'm confident that the process of reviewing the conflict will result in better guidelines. In that respect I feel confident that the potential for the abuse will be reduced.
As to Pete's level of engagement in Avalon - I have no idea what his intentions are. If he continues in Avalon he's going to have to learn to live with me. If he leaves, then Avalon has to learn to live without Pete ... and that has implications on our learning not be so comfortable with our dependence on Pete. Either way - Avalon will continue.
I think neither of them believes the issues on the table can be resolved.
I can only conclude that for some reason or other I represent a threat to Pete. It also a difficult issue to resolve because I'm not about to let Pete walk over me, intimidate me, or continue his vailed attempts at character assassination. On the other hand, if Pete chooses to be open and discuss the issues responsibly then I'm more than happy to work on that.
I have no idea where we should all go with this. I think we all as a community fail when feuds like this arise and can not be dealth with sensibly. Saddening :'|
Well don't give up just yet. Greg Stein (in the role of ASF Member) has been looking into the accusations that have been made and discussing this with both the Jakarta PMC and the Incubator PMC. It is my understanding that the Jakarta PMC discussions are related to the accusations and review of the actual facts whereas the Incubator PMC discussions are related to voting processes and guidelines. In effect, there really is a plus side to all of this!
At the moment I am just very concerned that fighting this 'battle' anywhere but outside the avalon community will hurt both our community and others. I am also concerned for the health of our project and other apache projects since it is apparantly very difficult to deal with these issues.
I am equally concerning about the negative impact this has on Avalon. On the other-hand every time there is a Pete/Steve battle, the hits on my home page go up. Yes, its negative publicity - but I bet more people are aware of Avalon as a result - and they are also aware that its an active project with an opinion.
I don't know where to go with this, don't know who is right, and don't know where things should go. I am unsure how to avoid situations like we have now in the future (though an answer might arise from the project guidelines @ incubator/commons, where fresh thought is going into these matters).
I'm going to go out on a limb here and explain what I think is the underlying problem. Its a problem rooted in the Jakarta PMC approach to project auditing. The approach basically assumes that there is a PMC member engaged in all of the projects. In the Avalon case, I believe the PMC considered Pete as a defacto representative. If this was the case, and if Pete was aware of this, then Pete failed to provide the appropriate guidance and independence that such a role would call for. If this is not the case, then the issue come down to the normal family problems that arise as we stumble along trying to sort out things that we should not normally be stumbling with. This brings me back to my earlier comment about an Avalon PMC - which is all about our taking responsibility for what we are, where we are going, and how we intend to get there.
I just think all committers should be aware of the issues and try and figure out what to do, if they can see a way out of deadlock. If that is impossible, I'd at least like Pete and Steve to make public their thoughts on this subject, so it is at least clear where we are all at. I don't think everyone realizes right now.
I do hope the information I have provided is helpful. :-\ Cheers, Steve.
best regards, Leo Simons
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
