Noel J. Bergman wrote:
I can give you my understanding (having gone though though this). If a committer has contributed to a particular source file, that contributor can -1 the action. Generally speaking the only course of action is for the community to lobby that committer to change his/her mind. There is a qualification that a committer must provide justification, however that justification may be totally irrelevant or oven irrationale. The committer right to veto holds. The standard solution presumed under the Jakarta framework is that the option is always available for a fork to take place. Within small scenarios this is workable - within larger scenanarios the single committer veto start to fall appart - because of the implications of forking of a large scale project. There is an option to request mediation from the Jakarta PMC - just email [EMAIL PROTECTED] with a request for assistance. I've been told not to do this in the past - but its clear from the reorg list that the PMC is there to work for you in thise sort of cases.Serge, Judging from "All other action items are considered to have lazy approval until somebody votes -1, after which point they are decided by either consensus or majority vote, depending on the type of action item" it seems that lazy simply means that it is accepted until rejected. On the one hand, it means that a Committer on vacation can't be "surprised" when he or she gets back. On the other hand, I don't see what (on paper) prevents a Committer from rejecting decisions made months or even years previously. Practically, this surely can't happen (or at least often), or nothing would get done. I'd venture that the rules work best where everyone tacitly agrees to seek the best solution for the project. I don't see what procedures are provided for resolving conflict, other than discussing it until everyone agrees on something. Other parts of the Jakarta site emphasis the importance of community building, so apparently part of the solution is getting along. In any event, I'd be interested in hearing more from experienced Apache members just informationally, but hopefully it won't be a practical issue here.
p.s. I don't know anything about the context of this dicussion :-)
Cheers, Steve.
Thanks for the kudos. And I agree with you regarding ASF. I think that it
is definitely the right kind of organization, with the best attitude towards
licensing, allowing a synergistic mixture of open (Tomcat) and closed
(Websphere) participants contributing to a common code base.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:sergek@;lokitech.com]
Sent: Friday, October 25, 2002 0:13
To: James Developers List
Subject: Re: Code change the Apache way
Noel,
Technically, I think you're right. I read this half a dozen times
before sending my previous email, and with another half a dozen reads,
I'm still confused but now leaning towards your interpretation. I was
deriving significance from the term "lazy", although it's never defined
in the document.
As for a clarification, you'll have to request one from the Jakarta PMC.
From my memory, I thought voting used to be typically majority-style.
But from this doc, a release plan and a release testing are the only
actions that are to use this vote-style. All others should ultimately
be consensus. I have to think this is backwards... changing CVS
requires consensus but making a release doesn't?
Anyway, kudos on being a committer. I firmly believe the ASF has
produced so much great stuff, and it's because it has the right style...
from licensing model to decision making approach to project proposal
credentials to culture. I think the interpretations and the future
re-org are relatively minor and just clarifying what's largely already
in place. (saying the rules and regs aren't heavy and not a big part of
the culture, imho.)
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
Noel J. Bergman wrote:
consensus.a code change [only needs] a majority vote (even a -1 isn't blocking).Please explain this. Because I really want to understand, and I had
understood it differently. From
http://jakarta.apache.org/site/decisions.html:
"Changes to the products of the Project, including code and documentation,
will appear as action items in the status file. All product changes to the
currently active repository are subject to lazy consensus."
I'd interpreted this to say that CVS changes are subject to lazy
And the document says that "[an] action requiring consensus approval mustdays
receive at least 3 binding +1 votes and no binding vetos."
Please explain where I missed the point, and where I can find more
illuminating information. I figure that between my being a new Committer,
the talk about a PMC, and having to stand in front of 600 people in 10
talking about all of the wonderful Java technologies from Apache, it is
probably a good idea to get more clarity on Apache's rules and regs. :-)
Thanks! :-)
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
