www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@wow.lk>
Subject Re: [important proposal] Cocoon as official Apache project
Date Wed, 30 Oct 2002 17:23:12 GMT
Given the revelation of lack of legal cover for non-PMC
committers I'm all for making every codebase a separate
PMC and allowing everyone committer to be a PMCer.

So, +1.


----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>
To: "Apache Cocoon" <cocoon-dev@xml.apache.org>
Cc: <community@apache.org>
Sent: Wednesday, October 30, 2002 7:29 PM
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
> 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
> 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
> 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

View raw message