www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@apache.org>
Subject Re: [important proposal] Cocoon as official Apache project
Date Thu, 31 Oct 2002 05:57:21 GMT
This is a bold step for Cocoon! Here's my enthusiastic +1 for this 

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.

Ovidiu Predescu <ovidiu@apache.org>

On Wednesday, Oct 30, 2002, at 05:29 US/Pacific, Stefano Mazzocchi 

> 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 cocoon-*@xml.apache.org mail lists will be moved to 
> {1}@cocoon.apache.org.
> 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                               <stefano@apache.org>
> --------------------------------------------------------------------

View raw message