Joe Schaefer wrote:
Stefano Mazzocchi writes:
[ I want to preface my comments by first thanking you for [EMAIL PROTECTED]
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.
Maybe you got me wrong: there is no problem with the actual release of the software.>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?
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 http://xml.apache.org/cocoon/who.html 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 developped.
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 <[EMAIL PROTECTED]> --------------------------------------------------------------------
