avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Charter.txt
Date Wed, 04 Dec 2002 11:32:46 GMT
> The PMC must have at least one officer from the Apache 
> Board, who will be the Chairperson and report to the 
> Apache Board.  See http://www.apache.org/foundation/bylaws.html 
> for reference. 

Doesn't this exclude Nicola from being chair? Or does it
mean that he will be appointed an officer upon becoming
chair? How does this impact the "rotating chair" proposal?

> In the unlikely event that a member of the PMC becomes 
> disruptive to the process or ceases to contribute for 
> an extended period, said member may be removed by unanimous 
> vote of remaining PMC members.

If we require unanimous vote, wouldn't it be more sensible
to have "for any reason" here? I mean, if everyone agrees
that I should be kicked out, shouldn't that then be possible
despite my once-a-year committs, and without having to
get into the nuances of what "disruptive" is?

> =========== 
> avalon.apache.org is comprised of subprojects; a 
> subproject is a component whose scope is well defined.  
> Each subproject has its own set of developers.  
> A new subproject proposal is submitted to the PMC, 
> accepted by majority committer vote, and then subject 
> to final approval by the PMC.

Is the final approval unanimous?

Is there any point in explicitely stating that even though
a subproject has its own set of developers, those
developers are not a separate part of Avalon - that is,
they can not exclude any other Avalon committer from
voting, etc.

Also, is there any point in specifying that sub-sub-projects
are disallowed? I don't want us to become another
Jakarta with subprojects 1000 levels deep.

> New committers are added when a developer is nominated by 
> a committer and approved by at least 50 percent of the 
> committers for that subproject with no opposing votes.  

Should be "approved by concensus", or 50% of *active*

> Specific changes to a product proposed for discussion or 
> voting on the appropriate development mailing list should 
> be presented in the form of input to the patch command. 
> When sent to the mailing list, the message should contain 
> a subject beginning with [PATCH] and including a distinctive 
> one-line summary that corresponds to the action item for that 
> patch.

How about we get patches into bugzilla instead? Cocoon has a very
nice patch queue that guarantees that patches aren't forgotten.

The above becomes:

The proposed changes, and the associated patch file should be 
filed as a bug in Bugzilla, with a short description beginning
with [PATCH]. The patch file should then be attached to the bug 
via the bugzilla attachment mechanism.

> For efficiency, some code changes from some contributors 
> (e.g. feature additions, bug fixes) may be approved in 
> advance, in which case they may be committed first and changed 
> as needed, with conflicts resolved by majority vote of the 
> committers.

Change to "may be approved via concensus in advance"


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message