cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [important proposal] Cocoon as official Apache project
Date Fri, 01 Nov 2002 00:47:15 GMT
Joe Schaefer wrote:

> Stefano Mazzocchi  writes:
> [ I want to preface my comments by first thanking you for community@.

You are welcome.

>   Secondly, at the moment I'm inclined to affirm your proposal, but I
>   need to develop some guiding criterion on which to base a vote.  I
>   don't want to be in a position where I feel obligated vote "+1" on
>   every similar request, especially when I have no feeling for how many
>   of them are coming :-) ]

Great. Thanks much for asking these specific questions, I think they 
might help much other people in the future.

Also, note that community@ is *NOT* asked to vote but only Cocoon 
committes. I copied community@ to let people know the process is 
underway and I wanted to do it in a very open way.

NOTE: so far, the counts is 16 positive votes (including mine) and not 
all committers have voted.

> >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).
> Can you describe the current release process for cocoon,
> emphasizing the problems with the current system?  Is there
> a public document that chronicles the issues?
Maybe you got me wrong: there is no problem with the actual release of 
the software.

The problem I have is that a container PMC is 'by design' composed by a 
selected number of committers while a software-driven PMC can be 
composed only by people that care about the software and know how to 
take action.

I think the second model is more effective than the first in any 
possible situation where legal issues emerge. And this is why I want 
Cocoon to have its own PMC: less indirection, more effectivness and 
better legal protection.

> >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.
> How many cocoon committers are there right now?
As you can see from there are:

  19 active committers
   5 inactive committers
  14 emeritus committers

see the page for a definition of their status and their names.

If the PMC was created today, I would like it to be composed of those 19 
active committers.

> >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.
> How will the cocoon PMC be better positioned to address the needs
> of such "subprojects" than the current jakarta/xml PMC?

In one word: focus. A PMC managing a project with a wide scope and 
hundreds of committers looses direct connection with the software being 

This has seveal big issues:

  - less legal protection (the PMC has a hard time to know what everyone 
is doing)

  - less communication (sub-projects tend to isolate from one another)

  - less foundation visibility (sub-projects tend to see the project as 
a sub-foundation, thus ignoring the foundation and reducing "vertical" 
communication between all layers of the foundation)

> How do you foresee cocoon's PMC addressing the current troubles with 
> subproject releases?

Like I said, there are no 'release problems', but the question is still 
valid if rephrased.

If a Cocoon PMC starts to become more and more a container, it will 
slowly start to behave like a sub-foundation (or to be perceived as 
such) and will then loose focus.

I honestly have no idea on how to handle this, but the intention is 
*NOT* to start having tons of new subprojects, but to go on with it 
*very easily* exactly to avoid this containment effect. At the end, 
Darwin will tell us what to do. As usual.

> >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.
> Among jakarta/xml projects, how widespread is the desire to abandon
> the container PMC?

Honestly, I have no idea. But I'm sure we'll find out really soon :)

Anyway, keep in mind that community@ is *not* directly involved in the 
process from a legal point of view. In fact, it's the ASF board that 
decides after the development community explicitly asks so (and that's 
why I started the vote on cocoon-dev@, our intention is to have the 
board pronounce at the next board meeting at the apachecon)

> Have there been other reorganization attempts in the past?

No, this is the first time.

Hope this helps.

Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message