From uima-dev-return-7601-apmail-incubator-uima-dev-archive=incubator.apache.org@incubator.apache.org Wed Jul 02 14:15:43 2008 Return-Path: Delivered-To: apmail-incubator-uima-dev-archive@locus.apache.org Received: (qmail 83167 invoked from network); 2 Jul 2008 14:15:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Jul 2008 14:15:43 -0000 Received: (qmail 36527 invoked by uid 500); 2 Jul 2008 14:15:44 -0000 Delivered-To: apmail-incubator-uima-dev-archive@incubator.apache.org Received: (qmail 36506 invoked by uid 500); 2 Jul 2008 14:15:44 -0000 Mailing-List: contact uima-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: uima-dev@incubator.apache.org Delivered-To: mailing list uima-dev@incubator.apache.org Received: (qmail 36495 invoked by uid 99); 2 Jul 2008 14:15:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jul 2008 07:15:44 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msa@schor.com designates 67.18.59.3 as permitted sender) Received: from [67.18.59.3] (HELO gateway05.websitewelcome.com) (67.18.59.3) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 02 Jul 2008 14:14:51 +0000 Received: (qmail 21322 invoked from network); 2 Jul 2008 14:24:28 -0000 Received: from gator74.hostgator.com (67.18.27.130) by gateway05.websitewelcome.com with SMTP; 2 Jul 2008 14:24:28 -0000 Received: from yktgi01e0-s5.watson.ibm.com ([129.34.20.19]:52054 helo=[9.2.34.126]) by gator74.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KE36t-00031A-AF for uima-dev@incubator.apache.org; Wed, 02 Jul 2008 09:15:03 -0500 Message-ID: <486B8D69.8060008@schor.com> Date: Wed, 02 Jul 2008 10:15:05 -0400 From: Marshall Schor User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: uima-dev Subject: Considering some re-org of SVN Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator74.hostgator.com X-AntiAbuse: Original Domain - incubator.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - schor.com X-Virus-Checked: Checked by ClamAV on apache.org I'm thinking about some re-org of our SVN layout based on these observations -We're getting a lot of components. Many of these are on somewhat different release cycles. -We initially had a "main" node, a cpp node, a site note and a sandbox node. The sandbox was for new-ish things. As some of these things get more "mainline" - it would make sense to have them perhaps under another node to indicate that. The idea would be that things in the sandbox were user-beware, but things in this other node were more "dependable" and "proven". Possible names for this other node might be: "parts". Or we might want to have several names that categorized the kinds of things - such as "annotators", "servers", "embeddings", "corpora", "typeSystems", "tools", etc. -The SVN conventions lean toward having branches and tags which are one level above the thing being released. Right now, for sandbox projects, these are 2 levels above the released thing. I think that, going forward, it would be better to go with the convention, following the convention-over-configuration philosophy, because the components are not likely to all be released on the same release cycle (although that would be a nice "goal" - like Eclipse does with it's many-part major releases). Other opinions? -Marshall