Le 18/07/11 20:56, Reinhard Pötz a écrit :
On 07/13/2011 09:30 AM, Steven Dolg wrote:
We should take a look at introducing "topic" specific modules.
I fear that the optional module turns into a giant clump of all things
unrelated.
Generally +1 to topic specific modules. As Steven already knows from
Indoqa projects, I'm a fan of many small modules ;-)
In regard to the still small C3 community (not in terms of people but
rather in terms of SVN changes and mailing list activity) we should
think about having a "Cocoon Stuff" project (analogous to Wicket
Stuff) where everybody that is interested gets commit rights. This
also clearly indicates what we as Apache Cocoon community consider
being officially maintained.
(BTW, the Wicket community is very restrictive in moving code from
wicketstuff.org into the wicket-core codebase because of the mentioned
maintenance reasons).
The wicket folks had a vote between hosting their stuff project either
at Github or at Apache-Extras (powered by Google Code). Github won and
the result can be found at http://wicketstuff.org/ and
https://github.com/wicketstuff/core
But there is also a downside:
- Cocoon release will become (slightly) more work in the future
because two code bases have to be released
- cocoonstuff.org releases are not ASF releases and we can't
rely on the ASF litigation protection mechanisms anymore
(which is also true for most opensource software out there)
(NB: That is the reason why we need 3 +1 votes of PMC members before
we can do a release and tag it with the Apache name)
- that the transition has to be done:
* contact the Apache Board about reserving the cocoonstuff.org domain
* decide what goes to cocoonstuff.org and what remains at
cocoon.apache.org
* rename all packages accordingly
* create a cocoonstuff-samples module
* decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for
all cocoonstuff modules
* decide about the release voting precedure
* setup a cocoonstuff.org website (if we use Github we could also use
it for hosting static websites)
* find out how to get the Maven artifacts deployed to the
central Maven repository
* find a solution for continuous integration (Jenkins) and providing
snapshot releases (Nexus?)
But IMO there is also an additional benefit: Creating cocoonstuff
would lower the barrier for contributions and could attract more
people to get involved with C3.
WDOT?
Hmm...
I definitely agree that modules specific to a 3rd party library or a JSR
that's not included in the JDK are to be packaged as separate artifacts.
As Steven rightfully points out, it's a real pain to download and
package a huge load of libraries you don't need. And this what has been
done in Cocoon since 2.0 with the large collection of blocks.
Now hosting these modules away from apache.org is a different thing that
has strong implications on community dynamics. The C3 community is
slowly growing after having been almost dormant for months (years?),
which is a very good thing, and I fear that a cocoonstuff.org would just
harm this nascent effort by splitting the still brittle community. Also,
a separate environment comes with additional time spent in
administrative stuff (look at your long task list!) that could probably
be used more wisely to build a stable C3.
So if the purpose is to lower the barrier for contribution, then why not
just having a "contrib" directory in SVN, clearly showing that these
aren't core modules, but still under the oversight of the PMC and the
ASF at large?
Of course, managing Git pull requests would be more convenient than
applying patches in Jira, but still, at this point, this is probably
easier than having a completely separate infrastructure.
My 0.02 cents.
Sylvain
--
Sylvain Wallez - http://bluxte.net
