Re: [A4] release plan thoughts

[Leo Simons]

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, well, you should not be a PITA but work on building consensus.

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?

- 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

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...

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.

- 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

Or both?

Container: <-- moved to Sandbox, Fortress need to be synchronized

If it is sandbox code, it shouldn't be a fortress dependency.

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.0

Thread: 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 needed

remove 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. 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 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?

- Fortress 1.0

After excalibur release.

that's exactly what I was saying, innit? :P

- 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.

- 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

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?

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.

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.

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.

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?

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.

cheers,

- Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]