On Wed, Feb 26, 2003 at 03:02:50PM +0100, Martin Holz wrote: > Jeff Turner <[EMAIL PROTECTED]> writes: > > > On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote: > > Why? Because then anyone can participate. It tears down any perceived > > barrier between cocoon-dev and cocoon-users. Best of all, when code > > eventually is 'promoted', there is a strong possibility of gaining new > > Cocoon developers. Think of it as housing "alpha committers" as well as > > "alpha code". > > > > The root problem is that Cocoon has more code than code maintainers. The > > long-term solution is not to juggle the code more effectively, but to > > gain more committers. THAT is why I think a cocoon-contrib @ sourceforge > > would be a win in the long run. > > There is nothing, that stops you to start a cocoon based project at sourceforge > right now. But I don't think, there should be no general coocon sandbox at > sourceforge,because it would favor splitting the community and it would > blur, which parts of cocoon belong to the cocoon core.
If it comes from Sourceforge, it's obviously not part of the core. As for community, it depends on if your definition includes users. Mine does, so I think it would actually help, by providing a common work area where committers and non-committers can work on things together. A Wiki for code. > Sourceforge would be a great place for several specific projects, that > use cocon,eg. a set of generators,transformers etcto transform Protein > Data Bank (PDB) files as SVG and Chemical ML, or components to interact > with SAP. But in practice, no-one bothers to create new SF project for one or two files. > If those components are mature enough and of general interest, they can > still move under the hood of ASF. > > A single cocoon sandbox on sourceforge would soon show the same bloat > like cocoon. As with Cocoon, bloat can be managed. In any case, a SF module bloated with code snippets is better than nothing, which is what we have now. --Jeff > Martin > > > >
