Stefano Mazzocchi wrote:
Stephen McConnell wrote:
Stanfano:
ahahah, 'Stanfano' in some italian areas means 'they stink', that's the most creative mispell I had in years, that's :)
Gosh - yes it was a misspeeling - sorry about that!
I rather surprised at your email - have included lots of comments/questions in-line.
Glad to surprise you.
Stefano Mazzocchi wrote:
This project has been making progress around working together but there are issues unresolved:
1) solidify excalibur but stopping it to be a moving target
This is already in progress.
I know.
A couple of months agro we started a coordinated release process commencing with the release of the LogKit package following by the framework. Work has moved on to the packages under the excalibur CVS with iminent releases of the component,testcase, instrument, instrument-manager, logger, and pool packages. Work in underway for the release of serveral additional excalibur components including the lifecycle package.
Wasn't the proposal about migrating the lifecycle package into framework or did I overlook something?
The proposal was to add the lifecycle package to the "avalon CVS" along side framework. This is consistent with the discussions concerning the structure of the avalon that we engaged in during the process of identifying Avalon scope relative to the PMC charter (i.e. there is a lot of discussion about this several months ago). Currently the avalon CVS is occupied by one project - the avalon framework. Peter Donald has suggested that the CVS structure is associated with some notion of quality - and that you grade quality downward commencing with avalon, next sub-category is Excalibur - etc. Presumably according to Peter Donald idea of CVS structure - the lowest point in the scale of quality is the sandbox. Personally I disagree with that position. In contradiction with the views Peter Donald, the discussions back during the formation of the Avalon PMC separated out the notions of utilities used to build containers from the notion of framework, meta model, framework extensions, container APIs, etc. The consensus was clear - the Excalibur CVS should contain those utilities we use in the construction of containers and components. A consequence of this discussion and consensus was the transfer of the "lifecycle" package from excalibur to sandbox. Since that time the lifecycle package has been in use - unchanged, by both the Fortress and Merlin containers.
As a result of the recent coordinated release process the lifecycle package is subject of an imminent release. If we follow the consensus established back when the PMC was formed - the lifecycle package should exist under the avalon CVS. Peter Donald has opposed that on the grounds that the package is a "hack" - a position which you have chosen to endorse - apparently without due consideration for the content or community supporting it. Neither you not Peter Donald have expressed any concrete opinions supporting the "hack" argument - in the meantime, discussions with users on the subject of lifecycle extensions has been ongoing on the avalon lists. I should not that those discussions have gone into a lot of detail as to the deference between lifecycle stage extensions as opposed to framework extension at the level of invocation policy. Peter Donald has suggested that "interceptor" solutions are preferable to the lifecycle extension interfaces developed by Berin, Marcus and myself. I should also note that Peter Donald, for whatever reason, has chosen to abstain from any participation or constructive contribution to that result. As such, it is difficult for me to understand Peter Donald's criticism at this time - just as it difficult for me to understand you endorsement of that criticism.
Bottom line - this is not a change to framework.
=>> 2) clarify the future of cornerstone
Work has already been underten to seperate individual Corenerstone packages enabling some degreee of release control. The release process for individual corenerstone units will be undertaken following completion of the dependent excalibur packages.
Good.
3) stop one-man-shows
Can you be more specific - what in you view are the one-man shows that must stop?
I don't see many people working on Merlin. Is this a wrong perception?
Leo Simons - has been active in his critique of the project since day one - has experimented with Merlin and validated the embedding of Merlin inside Oracle. Gary Shea has been testing and validating Merlin and providing valuable feedback include reporting on problems related to the original manifest formats resulting in the modification of Merlin to do a manifest independent scanning of jar files. Marcus Crafter has been working with Merlin as part of the work on the lifecycle interfaces and has reviewed Merlin in detail. The opinions on Marcus related to his work on the XFC project resulted in the separation of the meta model work into a separate project. Berin Loritsch has spent time looking into Merlin and posted several criticisms to this list concerning the complexity of the classloading mechanisms - resulting in a refactor of this entire sub-system. In addition Berin has initiated work on Fortress to Merlin Meta experimentation (although to be frank this is somewhat suspended pending the current release). Richard Wallace has been experimenting with Merlin in a web services environment and has provided valuable feedback related to limitations that existed at the level of kernel establishment in a non-expanded webapp context. Peter Royal has investigated the application of Merlin in the Mac OSM environment during which he located problems relating to the MacOS support of the shutdown hook - and issue that remains to be resolved. J�rg Schaible has provided really solid and constructive feedback on the use and application of Merlin in the servlet environment and has contributed patches supporting internationalization. J�rg's trials demonstrated that Merlin was changing a little too much relative to his development needs - however - his trials and feedback on the user list remain constructive and concrete contributions. Finally, Leif Mortenson has provided support for the establishment of the support for the Windows NT service deployment of Merlin. Today it is possible to deploy James as a composite component running as an NT service under Merlin based on the assistance and contributions from Leif.
Ok - that's just off the top of my head - if you want more details - I could go digging and double the length of the paragraph.
Are these one-man shows related to released packages, packages scheduled for release, or are you referring to activities under the avalon-sandbox project.
I'm referring to Phoenix and Merlin. Both seem to me one-man-shows. But hopefully I'm wrong.
You are wrong.
Merlin is alpha. As far as code commits are concerned it is largely driven my myself. As far as the content of those commits are concerned it is largely driven by the opinions and input of the community - in particular the input received from the [EMAIL PROTECTED] list has made a concrete and irreversible impact on the Merlin product. There remain some chunks of work on Merlin that are pending completion. Prior to completion that is not a lot of logic in having lots of people working on Merlin because things are changing too much. Given three or four weeks and maybe we will see a signal for a wider involvement - but for the moment the wider involvement is expressed through the list.
- o -
Peter said he didn't like your solution because he thought it was a hack. Guess what, I agree with him.
<snip-warm-and-fluffy-comment/>
Perhaps you could put forward you concrete arguments. Nothing below even suggests that you're familiar with the package in question. In fact several of the comments suggest that you may be confusing the lifecycle package with something else. You response on this is important because if you really think that the result of the collaboration between Marcus, Berin and myself is a "hack" - then I would like to discuss that will you. I will disagree with your position and present substantial evidence supporting that position. If however you comment is made with same level of indifference as the original hack comment from Peter Donald, then I can safely ignore it.
From there I stand:
1) something is moving into avalon framework
Incorrect - this is misinformation.
2) in my view of the world, this *something* is therefore going to be considered *ROCK* solid
It is a definition of a contract between a container extension and a container implementation. Implementations of the lifecycle extensions contracts have been implemented in both Fortress and Merlin. It is rock solid - proven, validated.
3) in my view of the way this project should work, *ROCK* solid is something where we have consensus and has been discussed by many more than three people.
The process of collaboration between Berin, Marcus and myself was very open. In fact there were occasions of disagreement in which a broad spectrum of this community got involved. This was a community solution - a solution with a level of quality that exceeds the framework itself.
4) a person that I technically respect highly believes that this solution is half-baked (hack is a bad term) and there are better solutions on the table.
This is enough set my 'serious avalon users' alarms off.
I respectfully suggest that you take the time and effort to asses this package independently. I am confident that you will find that the package simple, functional, usable and certainly beyond the characterizations put forward by Peter Donald.
If any of the above is wrong, please, enlighten me.
If there is anything in the above which is not sufficiently detailed - please let me know.
This project used to be the place where people discussed architectural issues about new paradigms that extended object orientation.
The lifecycle package was a successful process of collaboration by three people each with relatively different ideas on the approaches concerning lifecycle stage management under the Avalon framework.
I now see a forth disagreeing. This is valuable input from me.
It remains a good example of collaboration and effective resolution of architectural issues. Furthermore, it is a concrete demonstration of the willingness of different people to work together towards the achievement of common solutions on the container side of the Avalon equation.
Great, but now you are pushing this 'collaboration' at a higher level and this requires *more* consensus. Build it.
I'm not sure what you are talking about - "higher level". If you are talking about a particular level of abstraction in terms of "level" then what is inconsistent with the inclusion of the lifecycle extensions package into the avalon cvs. It clearly is inconsistent with the Excalibur package and its abstraction level of container and component utilities. I don't see it making sense inside logkit. The cornerstone cvs seems somewhat different and the avalon-apps CVS does not seem appropriate.
What happened to that?
Seems to me that it is alive and well. If you have been following the discussion here - there is a workplan that involes getting existing content released and managable, including the release of Fortress and later, Merlin. Berin and I have undertaken to work together on addressing the questions of ECM/Fortress component management in an architecture based on the Merlin Assembly package. This is part of the process of moving forward with the objective of resolving differences across Avalon.
Great.
But you are now moving stuff into avalon and one person strongly disagrees and another (me) wants to see why and wants to see more people involved when the framework gets touched.
The framework is not being touched.
The one person you refer to happens to have an idea about what it better and like4 to promote that idea over and above concrete, substantive and validated results established through collaboration across this community. Perhaps you could ask this person to put articulate his concerns as he has categorically failed to put forward anything of substance at this time.
the higher you get, the more consensus you need.
What is higher - is the work in sandbox any less quality that the work in avalon CVS? Are the components in Cornerstone subject to some lesser quality of compliance that the avalon CVS. This is absolutely meaningless.
This is the only way we can maintain oversight over a codebase that is sooooo-down-the-foodchain.
Since reaching consensus on Avalon 5 was too hard, several of you are trying to push your ideas into the framework by working it thru your one-man-show container.
I disagree. A5 is a subject that requires focus and solid consideration. I don't think a lot of progress will be made on that while the release process is underway. With the releases done, I fully expect the resumption of A5 discussions and hope that everyone here applies a constructive approach to the process.
>
This is the problem and Peter appears to be the only one *really* watching over what's going on in this project. Probably because he's doing some sneaky moves himself so he's more sensible about them.
I disagree. You comment ignores the time and effort people are putting into the release process. It ignores the time and effort people are putting into establishing a clean sandbox structure. It also ignores completely the community concensus reached on direction.
Sure, he uses his usual smartass tone that really used to irritate me, but I'm now able to sense his frustruation and I resonate with it.
Instead of putting forward a half-hearted attempt to justifiy the behaviour of Peter Donald
half-hearted? nono, full-hearted.
Every man is entitled to an opinion!
perhaps you could explain the frustrations that you resonate with. That would be constructive and helpfull (and
certainly more constructive and helpful than some of the suggestions you have made in your email).
>
One-man-shows have to stop.
*all* of them.
Please be specific and either identity the project in question or actually state the issue. If you referring to the work that I have been leading with respect to the Merlin project then say so (but please be prepared to present you case in the context of the community involvement in that project).
Go right ahead.
Ok - I have no problem with a reference to Merlin as a one-man-commit effort. Ok, technically I'm wrong - there are at least 3 others that have comitted to Merlin and at least 6 that has submitted patches. Bottom line - would I want it to be any different - yes and no. No in that I have may hands full getting Merlin to a state where I am ready to say to the rest of the Avalon Community "here it is, let's go". Until that time I'm happy to be somewhat in control. But please recognize that control is relative. Control in this context means multiple days responding to the wims of the avalon community. Ok, yes - it would be nice to have a couple of other comitters pumping away - but to be honest - its just not stable enough at this time and they would probably cause more work than assistance. Take for example the patches from J�rg to internationalize the command line interface - the CLI logic has been restructured and not the German language messages he submitted are inconsistent with the behavior.
To be really honest - a few more weeks is needed. The service access mechanisms on the Block interface need top be finalized and there is a bunch of documentation that needs to be updated. After that it's open game.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
