Leo Simons wrote:
Stephen McConnell wrote: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.
why? Are you jesting here? If you're serious,
A little bit of both.
If you look at the James usage of Cornerstone and the disconnection that has developed - it is really clear that we need to really upgrade our release process.
well, you should not be a PITA but work on building consensus.
OK - I'll be nice but rigerouse towards building concensus on the ACR (Avalon Coordinated Release).
:-)
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.
how about fixing the wrapper classes "to get things working properly" (regardless of where they go exactly, they're needed)? What is the exact problem?
From memory - its the ComponentSelector wrapper that does not wrap components returned from the ServiceSelector as instances of Component - i.e. a Component proxy is needed. The solution I put in place uses Proxy but that locks us into 1.3 of the JVM which (as par as I understand is not something we want to do to the Framework).
- Cornerstone (this badly needs a release I guess)Yes and no. Cornerstone (complete) sucks big time.
it sucks just a little. It's perfectly useful and has been in use in many places for a long time :D
No so.
The James depdency on cornerstone is a nasty mess. Changes have been made to Cornerstone components that have broken the James implementation. Result - there is a cornerstone.jar in James from back in June that is not maintainable in its current form. Cocoon also has a depdency on Cornerstone but in fact this is on one particular compoenent.
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.
are you planning on doing that work? I'm trying to get an idea of who is doing what...
The above seperation addresses the immediate needs of Cocoon and James - at least our needs to get those cross project dependecies into a managable state. Iwould like to people involved in other Cornerstone components to help migrate to seperate components - but this should tie into updgrading our build and release processes.
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).
I think they can wait till a release after the dependencies have been released. Chucking them in GUMP is a good way to figure out the actual dependencies.
Yep.
- 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 depreciateOr both?
Possible and probably a good idea.
Container: <-- moved to Sandbox, Fortress need to be synchronized
If it is sandbox code, it shouldn't be a fortress dependency.
It is in sandbox because its not released code. It needs to released. That's all.
Meta: moved to commons, Fortress updates needed.
the meta dependencies in fortress are seperated out into src/ng and not actually used. No updates needed.
Testcase: ???candidate 1.0Thread: release 1.0, candidate 1.1 (includes bug-fixes) Util: ???dunno.XMLUtil: apparent-candidate - has dependency on deprecated packages (e.g. collection - but not code ref) more info neededremove the deps, see if it works :D- 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.
hmm. ok.- 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.
ok. Ulrich (who's been testing it IIUC) sorta said the same thing.- 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.
I'm going to take your -1 as a statement of opinion only.
They all are - we are not voting here.
I think it's totally silly to not want to provide demos/examples. A testcase cannot fill the role of a demo. Many people learn best by example, and being able to drop a .sar into phoenix and see something happen is tremendously important, then being able to play with things and see what happens....it is vital for learning any place of software. If the demos hadn't existed 2 years ago I'd probably given up on phoenix when learning it, and I wouldn't have been typing this right now!
I agree totally - and as such this should go under Phoenix as a demonstration.
It should not be packaged as a released product because that's missleading.
I don't care what the quality or support status of the demos is. Alpha release is fine, just as long as it is at http://www.apache.org/dist/. It is not like one would want to mod the echo server if it doesn't echo some chinese character correctly. It's the drag-drop-it-works we need to show.
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
I was talking about ordering of releases here, not quality. SoC, dude :D
Here's the reasoning behind my ordering:
1) everything we release must work with the latest release of all of its dependencies
2) there's a dependency tree in gump (and my head)
1,2 ==> you start with the top of the dependency tree and work your way down
- all excalibur components used in fortress
See prior email - main issue is Instrumentation which needs to provide a RMI solution.
disagree. I don't need RMI Instrumentation in fortress. If we can get instrument to compile (should be easy enough) without needing altrmi then things are fine, right?
Instument isn't the problem - Instrument Manager is (as far as I can see). But your on the right track!
- Fortress 1.0After excalibur release.that's exactly what I was saying, innit? :P
Yes - it was late!
- avalon-apps/demo 1.0-1 on release +1 on moving this content into a testcase
-1 on moving the demo content into a testcase. If I should take your -1 as a veto (I don't think you mean it that way?), I'll 'fork' the demos to SF and release 'em from there if it makes you happy. Phoenix needs a demo sar or two. It really does.
I'm not vetoing anything - just expressing an opinion. Yes - it should be managed as a demo - no it should not be managed as an independent product release.
- altrmi 0.9
-1
get stable first on Excalibur, then look at what is happenging with AltRMI under incubator.
not much. By my estimate that's because incubator is shaping up, not because altrmi is shaping up :D
What is the timeframe/schedule for getting a release of AltRMI?
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.
so what is your schedule on backporting your improved assembly wrapper stuff to framework?
Don't have one - because of the 1.3 issue.
Tha't one reason why seperating the wrapper stuff into an external projuect gives us a little more flexibility.
a couple of weeks<snip/>a couple of weeks | Cornerstone Xxxx / Fortress
I think that at the rate we're going fortress and its dependencies will be ready for release quite soon.
I agree.
Phoenix / Merlin
I think Merlin is not ready for release as soon as the other stuff. I want more than a couple of weeks to digest it, get the terminology and docs right, etc etc. Merlin is much more revolutionary than the other stuff, and I think we should get it through an elaborate alpha/beta/release candidate cycle like we did for framework & excalibur 4.0 and for phoenix. This takes time and effort; we should first get the other stuff out and then refocus.
Yep.
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.
as long as it doesn't break the build or take months and months (as with our docs worries) I am happy with any setup that is an improvement over the current one.
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.
they reflect nothing more than demos. They are not suitable as testcases at all. QA on demos is not that important, just that they are available for the latest release.
Do you see the distinction I'm making between "demo" and "product". I don't want to see a version number and relase status associated with the demo.
What is really needed is a proper component test case.
well we need that as well. I don't plan to write one till we get to work on Spearhead though.
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.not a lot happening recently, looking at the mailing list.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.
how much work is this, how much does this impact our builds? What's maven's vector of change atm?
I've been using Maven as part of experimenting with relase control. The really big plus ius the ability to formally publish jars and jave builds locking into relased products (as opossed to our current process of validating against CVS). As far as impact is concerned - the build approach is indenpdent of Ant - much more structured - slower to execute - a lot more functionality and support for validation.
The best thing to do is to put in in place under one of the non-dependent Excalibur packages and set it up so people can see for themselves.
2. Sequence out process Logkit --> Framework --> Excalibur --> Cornerstone/Fortress --> Merlin/Phoenix
I think you shouldn't see excalibur as a single entity or a single release. The commonality with the excalibur projects is that the share the same cvs repo.
Yep - I agree. Cheers, Steve.
cheers, - Leo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
