Mailing-List: contact community-help@apache.org; run by ezmlm
Message-ID: <01f301c28039$0654ff00$d000a8c0@lankabook2>
From: "Sanjiva Weerawarana" <sanjiva@wow.lk>
To: <community@apache.org>
References: <3DBFDEA8.2000307@apache.org>
Subject: Re: [important proposal] Cocoon as official Apache project
Date: Wed, 30 Oct 2002 23:23:12 +0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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.

Sanjiva.

----- 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
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
>
>