james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject FW: [important proposal] Cocoon as official Apache project
Date Wed, 30 Oct 2002 16:09:53 GMT
If this mail gets through.. (its going via a server being load tested!)

I thought those not on the community/reorg lists might like to read this because Stefano outlines
quite well at least one view of the top-level-project issues.

d.


> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: 30 October 2002 13:29
> To: Apache Cocoon
> Cc: community@apache.org
> Subject: [important proposal] Cocoon as official Apache project
> 
> 
> 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>
> --------------------------------------------------------------------
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
> 


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message