Hey gang, I do not feel like adding merlin-specific meta descriptors (which is what .xprofile & friends are atm) to a package and then releasing that package. Reason 1: merlin is alpha. Reason 2: the descriptors are merlin-specific.
I am not particularly in favour of adding phoenix-specific meta descriptors to a package either, for the reason that they are phoenix-specific. However, phoenix is our only release status container within which it is actually easy to run most of the cornerstone stuff (IIUC), and it is not easy to run the cornerstone stuff in phoenix without the descriptors, hence they are a "neccessary evil". I suggest we release cornerstone with the phoenix-specific descriptors and nothing else. As we have already agreed that we need to support current phoenix users (which includes support for phoenix metadata) and phoenix-targetted components in future developments, it should be trivial to support cornerstone via that same route as well. IOW, I don't think adding more meta descriptors gets cornerstone into a "container-neutral" state, it is just adding support for more "non-standard" containers. Avalon is not at a point where "container-neutral metadata" is a reality, or likely to be there anytime soon (as in we'll probably take a few months). For cornerstone, stick to "minimal metadata targetting released avalon products" and provide a migration path to "container-neutral metadata" once we define "container-neutral metadata". All that said, this is IMHO and I don't consider this issue a release blocker; I definately don't want to spend countless days arguing whether we should or should not distribute those 10 xml files. For the general case, I stick by my "use only released code and concepts in releases". If this stuff does need to go in, mark it as "experimental". Enough about that. I'm definitely supportive of making a cornerstone release. Paul, you want to take on the task of release manager? If so, perhaps you could also document the steps of releasign as you take them on our brand-new wiki or somewhere else? (so I know the best way to do it for the next release :D) Note that for longer term I still believe that cornerstone should become out-of-scope and the components it contain IMHO should go someplace "common". Different issue though. cheers, - Leo On Mon, 2002-12-23 at 16:29, Stephen McConnell wrote: > Peter Royal wrote: > > > On Friday, December 20, 2002, at 07:45 AM, Paul Hammant wrote: > > > >> The transport package in the cornerstone project makes Phoenix > >> components of the server side of > >> AltRMI. Given transport is likely to remain alpha like Altrmi for a > >> while more, would it be > >> simplest to move the classes to the altrmi project? > >> > >> If so Cornerstone could be released as often requested? Thoughts? > > > > sounds good to me. > > -pete > > I think it would be really good if we could get the cornerstone packages > into a container neutral state before releasing. > > Cheers, Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
