On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:I think users should be able to do
cvs co jakarta-slide
ant
./slide
and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that).
I disagree. If we finally have a release why would any *user* want to do this?
because they download the binary distribution, then find a bug, then checkout the CVS module, then build.
If the build is not piece of cake, those guys will simply not continue and you loose yet another potential committer. Look around: you'll see that the simplicity of CVS building is directly proportional to the number of active committers that that project has. It's a cause, not an effect.
On the other side: I have seen so much branching and even painfully merged part of it myself, partly because people seem to be afraid to contribute their stuff publicly. If people get the impression everything that is in the CVS HEAD needs to be in production quality valuable contributions might be deterred.
Nah, slide is highly modular, you can plugin your new stuff without breaking anything (as you are doing with the new stores).
At the same time, if you change something that is core, this *must* be kept in production quality mode. that is: you should always do a clean build and pass the unit tests before committing.
using strict checking for core and looser checking for pluggable stuff will give you solidity and ease of innovation, without sacrificing one for the other.
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
