avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [A4] release plan thoughts
Date Thu, 30 Jan 2003 14:45:11 GMT
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message