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.

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:
>>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
consensus.
> And the document says that "[an] action requiring consensus approval must
> 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
days
> 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>

Reply via email to