Gerard van Enk <[EMAIL PROTECTED]> wrote:
Please tell us what you think about the document and about this subject.
I think the document is quite lucid. I would drop the notion of 'mmbase commons', becasue I think any mmbase applications should be reusable
in some way, so there need not be any distinction there. It would also
simplify matters because there are essentially only to kind of 'applications'
left then:
- community applications ('supported') - third party application ('unsupported')
I think by 'sandbox' the current 'speeltuin' is meant, which can remain to exist without any status, or mentioning in this document. Perhaps it could be mentioned in the guide-lines as a privilege of commitors ('commitors may use 'speeltuin' cvs module for MMBase related stuff, which has no status' or so)
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'm not sure what to say about chapter 3 about infrastructure.
I would perhaps suggest this
- supported application use tools of mmbase.org
- third party apps can either: - use 'speeltuin' if the app is a private thing of one of the commitors This option might be ignored in the document, because see above.
- 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.
- if a third party app will be adopted by the community soon, it might not
be wrong to avoid rigidity and e.g. offer CVS hosting in the mmbase.org
repository in an early stage.
That's true.
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.
Gerard
