commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: Status files and the Commons charter (was Re: cvs commit: jakarta-commons/math STATUS.html)
Date Mon, 06 Dec 2004 00:47:07 GMT

>>>Currently, the Commons charter states that a status file must exist,
>>>and, to date, I believe people have assumed that that file must be
>>>named either "STATUS.txt" or "STATUS.html". Since, as Phil says below,
>>>this status file is obsoleted by the combination of project.xml and
>>>changes.xml, at least for Mavenised projects, it might be worth being
>>>more explicit about this in the charter.
>>>
>>>So, we could add a clause to the charter that says that "the status
>>>file" is either (project.xml + changes.xml) for a Mavenised project,
>>>or STATUS.html or STATUS.txt for non-Mavenised projects.
>>>
>>>Comments?
>>
>>What version of the charter published here
>><http://jakarta.apache.org/commons/charter.html> says is
>>
>>"Each package is treated as a product in its own right.
>>
>>   a. Each package has its own status file, release schedule, version
>>number, QA tests, documentation, mailing list, bug category, and
>>individual JAR.
>>   b. Each package must clearly specify any external dependencies,
>>including any other Commons packages, and the earliest JDK version required.
>>         1. External dependencies on optional and third-party codebases
>>should be minimized.
>>         2. All necessary dependencies must be recorded in the
>>MANIFEST.MF file of the package JAR, in the manner recommended in the
>>JDK 1.3 documentation describing 'system extensions'
>>   3. Each package must maintain a list of its active committers in its
>>status file."
>>
>>The statements above indicate that the basic information should exist in
>>a single file.  Seems to me that the info in project.xml by itself
>>serves this purpose; though it might be better to change the wording as
>>you describe to explicitly allow it.
>>
>>I will gladly revert the commit below (and update the STATUS.html file
>>so it matches the release) if you or anyone else really feel that
>>dropping it violates the j-c charter.
> 
> 
> No, I don't believe that's necessary. If I did, I would have vetoed
> the commit, which I didn't do. ;-) All I'm suggesting is that we might
> want to clarify the charter to be more specific about what file "the
> status file" actually is. Really, a status file isn't very useful if
> people don't know where to find it. ;-)

I agree. The key is making the core "status" information easy to find, 
and the traditional base directory location is best, IMHO. Here is a 
stab at a revised version of the section above:

a. Each package has its own release schedule, version
number, QA tests, documentation, bug category, and
distribution JAR files.

b. Each package must clearly specify any external dependencies,
including any other Commons packages, and the earliest JDK version required.
   1. External dependencies on optional and third-party codebases should 
be minimized.
   2. All necessary dependencies must be recorded in the MANIFEST.MF 
file of the package JAR, in the manner recommended in the JDK 1.3 
documentation describing 'system extensions'

c. Each package must maintain a status file including a brief 
description of the package, information on the latest release version, 
all dependencies, and a full list of active committers.  This file 
should be located in the project's base directory, named either 
STATUS.html, STATUS.txt or project.xml.

Note that I made a couple of additional changes to part a. -- not 
requiring each package to have its own mailing list and allowing 
multiple distribution jars.

One small but important point here is that, at least as far as I know, 
there is no place in project.xml to specify required JDK level, as 
required by part b, so components that don't include STATUS.html need to 
document this on their web pages somewhere.

Phil
> 
> --
> Martin Cooper
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message