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 allows us to host several different incubation-stage efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins could be possible additions. Of course, with the idea of promoting them as top-level projects when they are successful from a community perspective.
Also, it means that we could have our own machine running the entire cocoon.apache.org web site (that means: finally having Cocoon serving its own pages!)
Last but not least, it will give much more visibility to Cocoon since it will be visible directly from www.apache.org
4) what are the drawbacks?
moving stuff around is always annoying, but I think this is the only major drawback.
5) isn't this unfair against the other sub-projects that remain contained, therefore with less visibility?
I don't know. Here I'm just stating the intention to move Cocoon to top-level and I know the ASF board is very open to projects willing to move out of their containers.
But the ASF will *NOT* force projects to take this action. If other communities feel they should deserve top-level projects, they should make a proposal like this and ask the board instead of complaining with us that we do it.
6) isn't a cocoon-related project too specific? wouldn't it be better to have something like 'publishing.apache.org' and host all publishing-related stuff there?
No, it would be a smaller container, but still a container where the PMC and the committers are not the same entity.
HTTPD is a project about a modular HTTP server written in C, it's not a container for all HTTP-related server technology, nor it would be of any help if it became one.
I think the ASF should stop forcing project to remain in containers but simply allow them to choose to step up.
Cocoon.apache.org will be the community of people around Cocoon and will host, develop and distribute cocoon and cocoon-related software. And the PMC will be directly supervising because it will be composed by all committers of all cvs modules it will host.
Also, stuff like Cocoon is very hard to make it fit into a single category.
7) how do we move this further?
First thing to do is to have a formal votation. All committers should express their vote on this, right here:
[ ] +1 I think it's a good idea [ ] 0 I really don't care. [ ] -1, I don't think it's a good idea.
Please, vote clearly so that it's easy to make good summaries. If you vote -1, please state your reasoning and propose a creative solution for the problems this proposal tries to address.
After the votation we'll see what to do.
Thanks.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> --------------------------------------------------------------------