This is a bold step for Cocoon! Here's my enthusiastic +1 for this
proposal!
My only concern is that Cocoon will have a lot more pressure on it when
this happens, but in the long run this pressure should help us polarize
in the right direction.
Greetings,
--
Ovidiu Predescu [EMAIL PROTECTED]
http://webweavertech.com/ovidiu/weblog/
On Wednesday, Oct 30, 2002, at 05:29 US/Pacific, Stefano Mazzocchi
wrote:
Ladies and gentlemen,
it is with *great* pleasure that I'm finally feel confident enough to
ask you about something that is been in the back of my mind for more
than a year now.
The proposal of making cocoon an official top-level Apache project.
- o -
Before I state the proposal and its implications, allow me to
introduce the context.
Currently, Cocoon is not officially considered a 'project' under the
ASF bylaws. Cocoon is, in fact, part of the Apache XML Project just
like Xalan Xerces Fop Batik and the others.
The ASF was designed round the concept of having one big legal
umbrella (the foundation) and several focused development communities
(the projects).
The original idea was, in fact, modeled after how the Apache Group
managed the Apache HTTPD project.
Unfortunately, the ASF members thought that the same model could well
apply to projects which did not release software directly (unlike
HTTPD did) and decided to use the same model for jakarta and xml
(which don't release software directly, but add another level of
indirection with subprojects).
The concept and the term subproject was, in fact, invented to
separate the development community from the container.
Over the years, it became clear that project containment yields
several drawbacks:
1) container PMCs don't do anything since they are too detached from
the actual code (it's impossible they know all about all the code
hosted by the single containers!)
2) the subproject committers never have a way to interact directly
with the foundation, thus they perceive it as a distant and
bureaucratic thing
3) the ASF doesn't have proper legal oversight on the code contained
in all sub-projects
4) the trend of sub-projecting created sub-containers (avalon and
turbine, for example), thus making all this even worse.
5) the creation of sub-brands and the confusion this created.
Example: is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
Over the last 18 months, several members tried to convince the ASF
board that this situation was potentially very dangerous since, in
fact, the container projects started to behave more and more as
sub-foundations, but without the proper legal understanding. This
situation was potentially inflammable in the case of a legal action
against a committer since the foundation might not have been able to
properly legally shield that committer since it operated outside the
bylaws and without proper PMC oversight.
Over the same period, several very influential members and board
officials were against this notion, stating that it was just a human
problem with the people elected on the PMC and *not* a problem in the
design of the foundation.
After a few new PMC elections, and after finally having a jakarta/xml
member elected on the board (Sam Ruby), things are finally starting to
change.
The ASF board agrees on an open policy on the creation of new
top-level Apache projects in the spirit of HTTPD: that is 'one PMC one
codebase'.
So, in the light of this, I would like to hear your comments on the
idea of moving out of xml.apache.org into our own project.
- o -
Before you start asking a bunch of questions, let me answer a few of
them that I might consider FAQs.
1) what are the contract changes that the proposal implies? [note, all
these are not carved in stone, but just here to give you an idea]
Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
redirected.
The [EMAIL PROTECTED] mail lists will be moved to
[EMAIL PROTECTED]
The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1
module moved into hybernation state and stored for historical reasons
only.
NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
need to change anything there. [I planned this in advance at least two
years ago, so that's why the namespace was already clean]
2) what does it mean for the developers?
An official Cocoon project will have an official PMC which is what is
legally reponsible for the code and reports directly to the board. The
PMC officer becomes a vice-president of the ASF.
In order to avoid stupid PMC elections, I'll be in favor of having the
PMC composed by *all* committers that ask to be part of it. This to
imply that committers and legal protector share the same duties and
priviledges.
In short, it means that if any of us screws legally, the foundation
will protect us. Today, this is not the case.
3) what does it mean for Cocoon?
Being a project
