Gerard van Enk <[EMAIL PROTECTED]> wrote:
I think it's necessary to have a commons-main and a commons-sandbox.
Sandbox (indeed the current 'speeltuin') is a place where commitors can try new ideas, create tools they need, start experiments, etc. Some of these pieces will survive others will die in the sandbox. The ones that survive will be promoted to the commons-main. This way if you're interested in 'living-on-the-edge' code you know where to find it and if you're only interested in stable code you also know where to find it.
I think for living-on-the-edge code you could use the 'unstable' cvs branch, also for 'applications'.
Thats true, but imho not everything can be put into the applications module.
[...]
- or use mmapps.sourceforge.net. I suggest we mention this initiative as
clearly as possible. Because we promote a clear alternative for being on
mmbase.org itself then.
Why an alternative? We could use mmapps.sf.net as a starter, but I think it's best if things like these are on mmbase.org, so people know where to find it. True, we could link to mmaps.sf.net, but I'd like to have it somewhere on mmbase.org.
Perhaps, but we are risquing having to reimplement sourceforge ourselves then, which I think is a hopeless goal. I don't think it is such a bad idea to utilize sf itself then, for all initiaves the community itself cannot or doesn't want to occupy itself yet.
I'm not talking about reimplementing sf, just choose the best tool :).
I think we need to have different kind of commitors, eg core-commitors and non-core commitors. This way not every commitor has to have inside knowledge of the core.
Perhaps yes. We should think then about how to enforce this in the CVS setup then (I think UNIX security must be used then, so the rights groups/users need be created)
Jep, maybe take a look at apache, because they're using 1 big cvs, but a commitor can only commit in their part of cvs.
Gerard
