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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
- Re: [important proposal] Cocoon as official Apache pro... Stefano Mazzocchi
- Re: [important proposal] Cocoon as official Apach... Marcus Crafter
- Re: [important proposal] Cocoon as official A... Torsten Curdt
- RE: [important proposal] Cocoon as official Apach... Carsten Ziegeler
- Re: [important proposal] Cocoon as official A... Gianugo Rabellino
- Re: [important proposal] Cocoon as official Apach... Bertrand Delacretaz
- Re: [important proposal] Cocoon as official Apach... Peter Royal
- Re: [important proposal] Cocoon as official Apach... Vadim Gritsenko
- Re: [important proposal] Cocoon as official A... Stephan Michels
- Re: [important proposal] Cocoon as offici... Nicola Ken Barozzi
- Re: [important proposal] Cocoon as official Apach... Steven Noels