avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [A4] release plan thoughts
Date Thu, 30 Jan 2003 16:57:41 GMT


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


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.0 
>>
>>
>> After 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




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