Leo Simons wrote:
Hi all,
Hi Leo. Lots of comments in line. :-)
Getting our act together
========================
with that pmc vote process just about out of the way (thanks Leo!), infrastructure setup coming along nicely, would it be a good idea to set up a release plan for an across the board avalon release? Do people agree it is worth setting up some rigid structure to be able to get releases out? Are we ready for that?
I think we are :D
Me too.
I started on a release plan, but I kinda found I don't know enough about some excalibur and cornerstone components in order to make any kind of sensible comment there. Is there someone who wants to take on the task of release manager, write up a release plan, schedule, etc? I will try and do it if needed but I feel there's better people for the job.
I am prepared to take on Release Manager if needed - but I'll probably be a PITA. So if someone else wants to take on the job - please volunteer now. If someone else does volunteer - well - I'll still be a PITA.
Things on our plate
===================
- Phoenix 4.1 (dependendent packages refactored recently, many features that didn't go into 4.0 now making it in IIUC)
- Fortress 1.0 (first release obviously)
- Framework 4.1.4 (javadoc changes, the wrapper classes, some additions to ConfigurationUtil, more tests I believe)
I have a problem with 4.1.4 in its current state. My experience with the wrapper classes was less than positive and resulting in my forking the particular classes into Assembly to get things working properly. I would prefer that we pass on a framework release and instead - put the wrapper classes into Excalibur Component or a new package like Excalibur Legacy. I don't want too see the crown jewels going out with stuff I know is incomplete and insufficiently tested.
- Logkit 1.1.2 (logfactor 5 additions, other than that I dunno but I do know some features were added)
OK.
- Cornerstone (this badly needs a release I guess)
Yes and no.
Cornerstone (complete) sucks big time.
The only rationale release approach is to break these down into individual components. I've done this for the following:
cornerstone-datasources-1.0.jar
cornerstone-connection-1.0.jar
cornerstone-masterstore-1.0.jar
cornerstone-scheduler-1.0.jar
cornerstone-sockets-1.0.jar
cornerstone-threads-1.0.jar
None of the above have a dist target so more work is needed. In addition - the release of these components can wait until after an Excalibur general release (because they are tied to at least Excalibur Threads 1.1 which is a release candidate + other Excalibur packages).
- Lots of excalibur packages (seperated out, bugfixed, new packages etc etc)
What I know about CLI <-- should be depreciated in favor of Commons CLI Component <-- used depreciated collections package // either we upgrade or we depreciate Configuration: candidate 1.0 Container: <-- moved to Sandbox, Fortress need to be synchronized Datasource: <-- contains some alpha jars - need input here Event: released: 1.0.1 candidate 2.0 <-- but Berin needs to provide status I18N: released: 1.0, candidate 1.1 Logger: current 1.1, needs to be bumped to 1.2 with recent additions Meta: moved to commons, Fortress updates needed. Monitor: should be released under 1.1 following a sourceresolve release Pool: release 1.1, candidate 1.2 (updated to commons collection) Sourceresolve: possible-candidate needs test cases and more doc Store: apparent-candidate, more info needed Testcase: ??? Thread: release 1.0, candidate 1.1 (includes bug-fixes) Util: ??? XMLUtil: apparent-candidate - has dependency on deprecated packages (e.g. collection - but not code ref) more info needed
- AltRMI (I'm guessing it is just about ready for release? Is this baby so big we want to do it seperately?)
My understanding is that this is not a release candidate and is also under discussion as an incubator project. I suggest we leave this off the agenda for now.
- Sevak (alpha release, at least? Paul?)
I don't think this is a good idea - I would prefer some more "cooking" on this project. All my experience suggests that the Servak interfaces are not sufficient. I'm saying that this needs more time to evolve.
- Demo apps (should we just provide the .sars in the phoenix distribution or release these seperately?)
-1 Demo apps should be converted to test cases.
Ordered releases
================
Except for AltRMI perhaps (I believe it is really loosely coupled now?), I would think it makes sense that we do a coordinated release of all packages. Perhaps a good order would be:
- Logkit 1.1.2
+1
- Framework 4.1.4
-1 (see above notes and Excalibur L:egacy allternative)
- all excalibur components used in phoenix (ie stuff like baxter)
+1 on all excalibur components that have rational relaase plans and stable status.
- Phoenix 4.1
-1
Sort out Excalibur first. After that there is a test and validation pahse to run through with Phoenix.
- all excalibur components used in fortress
See prior email - main issue is Instrumentation which needs to provide a RMI solution.
- Fortress 1.0
After excalibur release.
- remaining excalibur components 1.0, 1.1, 1.2 releases
After excalibur release.
- cornerstone components
Only as seperate and mangable components. Only after Excalibur.
{- point releases for catching any serious bugs}
- avalon-apps/demo 1.0
-1 on release +1 on moving this content into a testcase
- sevak 1.0
-1 More cooking needed.
{- point releases for catching any serious bugs}
- altrmi 0.9
-1
get stable first on Excalibur, then look at what is happenging with AltRMI under incubator.
where after each component release, the other projects are updated, branched if neccessary (I think logkit and framework can do with tagging, phoenix is already properly branched), to be compatible with their dependencies. For example, we branch stuff like baxter into a stable branch which compiles against framework 4.1.4, and excalibur-logger into a stable branch which compiles against logkit 1.1.2, etc etc.
Status/Schedules
================
What's people's ideas on time schedules? IMO, logkit and framework are ready for release right now, someone just needs to do the work.
I'm OK with logkit - I'm not of with the wrapper stuff in Framework.
I haven't done any phoenix testing on the refactoring changes Paul did, but I'm relatively sure it's pretty good to go as well. Paul?
Framework/Logkit | V a couple of weeks | Excalur xxx | | V a couple of weeks | | V Cornerstone Xxxx / Fortress | | V a couple of weeks | | V Phoenix / Merlin | | V a couple of weeks | | V James rollup
Fortress itself is nearing the quality needed for a 1.0 release, but I don't know if that is true for all its dependencies. I'm a bit hung up on "remaining excalibur components 1.0, 1.1, 1.2 releases"...Steve, how confident are you wrt your product table accuracy? Can we base decisions of that? Also, how are things going with cornerstone refactoring? Have you got a time schedule for that in mind?
Product table is already out of date. Automation is an absolute necessity here. I would like to propose that we adopt Maven as the build management framework across all of our projects. This will all the seperation of the CVS build from published releases in a consistent manner. I have been working with Mavan and am reasonably happy with the resolutions on the management side - no so happy with the doc generation side but that's a secondary concern. I'm confident that Nicola can deliver the solutions we need there. I'm also concerned about the James process - they are talking about moving over to Maven and the bottom line is that they (at the end of the day) will need commensurate support from ourselves.
As to the question - Excalibur - more info needed on Event from Berin (feeling a little shaken by recent changes even though I think they are positive). Several candidates release candidates detailed above. Cornerstone should wait for a subsequent stage - but not long. Both Cocoon and James have dependencies on non-release Cornerstone code. Even worse James appears to be using some special variant that I have not figured out (but things are moving towards a manageable synchronization with Avalon). Bottom line - Cornerstone sucks big time in its current form - but there is hope - with separation we can build a series of manageable components. But it's a post Excalibur release concern.
The demos have been in use for ages, and they are definately good for release.
Disagree - the have been changes and it really only reflects nothing more that a test case. What is really needed is a proper component test case.
I dunno about sevak, but I have a hunch a release is desired by more than a few of our users.
I'm not happy with Servak - would like to se more "community" discussion on this.
I've been writing some code on top of altrmi, and it feels really good; I haven't encountered a problem yet, but I also don't know the code so I can't say. In the altrmi case, I would like a release as a user :D
I would like to see an update of the status of dicussions on incubator.
Let's do it!
============
Have we got the time, energy and spirit to stick our heads together and get some overdue products out? I think we do.
Me too - but one step at a time - and lets do it in a manageble process.
1. Get in Maven acrosss the board.
2. Sequence out process Logkit --> Framework --> Excalibur --> Cornerstone/Fortress --> Merlin/Phoenix
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]
