Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3DBFDEA8.2000307@apache.org>
Date: Wed, 30 Oct 2002 14:29:12 +0100
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2b) Gecko/20021016
MIME-Version: 1.0
To: Apache Cocoon <cocoon-dev@xml.apache.org>
CC: community@apache.org
Subject: [important proposal] Cocoon as official Apache project
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org