Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 42360 invoked from network); 6 Jan 2003 11:08:20 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 6 Jan 2003 11:08:20 -0000 Received: (qmail 22841 invoked by uid 97); 6 Jan 2003 11:09:48 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 22807 invoked by uid 97); 6 Jan 2003 11:09:47 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 22794 invoked by uid 98); 6 Jan 2003 11:09:47 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Injected-Via-Gmane: http://gmane.org/ To: avalon-dev@jakarta.apache.org Path: not-for-mail From: Leo Simons Subject: Re: Containerkit Date: Mon, 06 Jan 2003 12:10:18 +0100 Lines: 57 Message-ID: References: <3E18B600.3010301@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en In-Reply-To: <3E18B600.3010301@yahoo.com> Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Paul Hammant wrote: > Folks, > > This package is now in avalon-sandbox. Given it is used in Phoenix, has > code that was refactored from Phoenix, I think it is best not to mark > this package with the 'alpha' status that sandbox affords. Containerkit is not 'alpha' in the sense of code quality. It _is_ alpha in the sense of "we're not guaranteeing backwards compatibility on this stuff (we're not done yet with the meta model disucssion)". As such I think it fits in sandbox. However, if containerkit is used and needed in phoenix (looking at my current phoenix lib dir, it's not, but the info package in sandbox is, so the principal discussion is the same), and it's alpha state is hampering phoenix development (which is why you're posting this message, innit?), we need to find a way arround that. > I'd like to see how people feel about ... > > a) removal of containerkit from sandbox to some place more fitting I think it fits where it is right now :D > b) absorbing of containerkit into Phoenix (giving it x.x.phoenix > packages). Given the speed the "common ground" discussions are taking I think this is the best compromise. I am a bit concerned about later backwards compatibility (if the final "common meta setup" we agree upon deviates a lot from the one currently used in containerkit/info/phoenix, it'll be a lot of work to get phoenix to support both). Given recent developments at work, it is unlikely I'll have the time to invest to do that conversion work (you might notice me working on fortress though ;), so I won't give a +1, but if there's enough peeps willing to commit to it, then I certainly don't have any other objection, and I'll give an as-supportive-as-possible +0 on option (b). I would like to see the coupling between phoenix and a specific meta model kept as small as possible though, with the eye on easing migration to something else later. I'd also like to see some notice in the phoenix documentation that although the meta materials are stable codewise (and supported as such), we're not too sure about some aspects yet and thus that there may be big changes in future versions (as we already know this, users should know too :D). I do think a version of containerkit should remain in avalon-sandbox as there's stuff to harvest from it in the continuing "common meta setup" area. cheers, - Leo -- To unsubscribe, e-mail: For additional commands, e-mail: