On Fri, 25 Oct 2002 17:32, Justin Erenkrantz wrote: > --On Friday, October 25, 2002 5:20 PM +1000 Peter Donald > > <[EMAIL PROTECTED]> wrote: > > Sounds kool. > > > > One thing that jumps into my mind. Are we going to set a minimum > > bar of entry for commons projects? Or at least a minimum bar for > > release of said projects? > > For now, you have to convince the PMC. In serf's case, we have a > very stacked deck, so it's not quite fair. =) And, my personal > position is that the barrier would be pretty low.
okay. > 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. who cares on these things. The point I was trying to make is about the artefacts that effect external users and the process. For example. many of the things jakarta has been criticised for by users (and rightly so imho) is things like; * lack of documentation * no uptodate website * lack of documentation * multiplicity of versioning schemes * lack of documentation * no unit testing * lack of documentation * ignoring backwards compatability * lack of documentation One thing I would love to see is some documentation about the process. For example I would love to see some docs such as the following collated and used as reference. They could just be "guidelines" and people could be free to ignore them. Of course not all of them are relevent for all languages while some are. Anyways here are some examples; Releasing: --http://cvs.apache.org/viewcvs.cgi/jakarta-ant/ReleaseInstructions?rev=1.9.2.1&content-type=text/vnd.viewcvs-markup --http://jakarta.apache.org/turbine/maven/development/release-process.html Branching CVS (and presumably Subversion): --http://jakarta.apache.org/turbine/maven/development/branches.html Versioning (C specific but with slight mods could be java aswell): --http://apr.apache.org/versioning.html Deprecation Rules (java specific?): --http://jakarta.apache.org/turbine/maven/development/deprecation.html etc. It would also be nice to have a minimum standard for producing documentation when releases are made. (Unit tests would be nice but consesus would be impossible...) So don't think of it as what style your code is in or whether to use GNUMake, Ant or someother tool. Think of it more as process. It need not be inforced but it could be recomended. I know some people will have their own religion regarding different parts of process but if we could document a base standard then that would be great. I am happy to do the collating and if anyone else has any specific guidelines then they should feel free to rewrite one of the above or whatever. So is that a useful thing for us to do? And if so does anyone have any other process docs they would like to add? If it ends up being successful we can always push it back to www.apache.org but until then it could be just what we recomend to components. Like or no? > (One > reason I'm against using Ant commons-wide - it sucks for C code which > is about all I care about.) -- justin yes - using Ant for C is about as much fun as sticking hot pokers in your eye (and thats coming from an ant committer ;]) -- Cheers, Peter Donald ----------------------------------------------------------------------- | I thought there was a knob on the TV to turn up the intelligence. | | There's a knob called "brightness", but it doesn't work. | -----------------------------------------------------------------------
