From bayard@generationjava.com Fri Oct 25 14:47:25 2002 Return-Path: Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Delivered-To: mailing list general@incubator.apache.org Delivered-To: moderator for general@incubator.apache.org Received: (qmail 19116 invoked from network); 25 Oct 2002 14:47:25 -0000 Received: from umbongo.flamefew.net (64.253.103.114) by daedalus.apache.org with SMTP; 25 Oct 2002 14:47:25 -0000 Received: by umbongo.flamefew.net (Postfix on SuSE Linux 7.1 (i386), from userid 500) id 1D72F3A2482; Fri, 25 Oct 2002 10:47:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by umbongo.flamefew.net (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 1C3B1296D5B; Fri, 25 Oct 2002 10:47:26 -0400 (EDT) Date: Fri, 25 Oct 2002 10:47:26 -0400 (EDT) From: Henri Yandell X-X-Sender: To: , Cc: Subject: Re: APR-Serf In-Reply-To: <3DB95679.5040403@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 25 Oct 2002, Nicola Ken Barozzi wrote: > > /CCing incubator/ > > Henri Yandell wrote: > > > > On Fri, 25 Oct 2002, Justin Erenkrantz wrote: > > > > > >>I also don't think that the PMC should set guidelines on a release > >>(other than 3 binding +1s) or on coding style or on build systems. > >>Leave that up to the committers. The PMCs job should be to stay the > >>heck out of the way of the committers. If the committers need help, > >>they can ask the PMC for guidance, but let's not have a PMC that > >>dictates from upon high. > > > > I'm assuming other things would exist. A project must have a > > PROPOSAL.html. A project must maintain a STATUS.html. A release must have > > a release manager. > > In Forrest, we have decided to keep the information about the project in > xml files. > > Module.xml is a descriptor of the CVS module and the project it > contains, with goals, license, credits, project-related info and > dependencies with other projects. > > In status.xml there are the committers, the todo and the changes. > > Forrest already makes info based on status, and we'll get module.xml > done too soon: > > http://xml.apache.org/forrest/changes.html > http://xml.apache.org/forrest/todo.html > > What do you think, could this be an option? > I'm not that bothered, so I'll immediately be a hypocrit and suggest +ves and -ves. XML is a better storage mechanism but a worse presentation mechanism [using w3m to view an xml file probably isn't as exciting as a html. but it's a minor thing outweight by the advantage of a structured file]. XML is usually a finite domain, whereas HTML is infinite. By that I mean that if we used XML to record this information then it would as I said be more structured, but would also be limited. If someone wanted to add some more information, then they have to request new tags? Or would it be free-flow xml? In a HTML one the information is unbounded but unstructured. I guess it just depends on whether the existing proposal/status files out there are deemed to be enough evolving to define a standard. Which brings on the arguments over whether maven's project.xml, forrest's module.xml etc should be the standard :) Really my initial mail was that the information in PROPOSAL.html and STATUS.html should exist in each project, and that A-C as a project probably wants to standardise how to store this information. Using the same system as J-C is not mandatory.