incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: veto stuff
Date Thu, 07 Nov 2002 22:35:51 GMT
+1 on everything you said. 

The only problem is that this assumes a functioning PMC who cares about;
* the "Apache way"
* the project in question

So far the Jakarta PMC has chose not to take any action. 

On Fri, 8 Nov 2002 05:18, Rodent of Unusual Size wrote:
> [long]
> Nicola Ken Barozzi wrote:
> > > no, because that makes it a requirement that there
> > > essentially be *two* -1 votes.
> >
> > Well, no. It happenes that someone vetoes something with a rational
> > explanation, but the other side has equally compelling reason to have
> > the commit pass.
> no.  there is no 'equally compelling reason' that can override
> a veto.  it's not about opinion, but fact.
> > Not everything is bitwise, especially in framework projects
> > where it's all very conceptual.
> if the veto/+1x3 policy applies, it is absolutely
> bitwise.  if it doesn't apply, use a different policy.
> > It has also happened that a justification for a veto was
> > deemed null by the original committer because he effectively
> > didn't concede it was correct, while the other says it is,
> > and the community splits between the opinions. (hence the
> > following point 3)
> as stated, this is completely unambiguous: the original committer
> is in the wrong.  if the justification for the veto was on other
> than technical grounds, it may have been invalid; if the justification
> was technical (and not *demonstrated* to be incorrect), the
> veto was valid.  not only should the original committer have
> honoured it, but the community should have enforced it.
> all hypothetical and highly situational w/o knowing any actual
> facts of any such incident.
> > This really disturbs me, the fact that when these things
> > arise there are no rules I am aware of that are used in
> > not keeping the community at the mercy of these guys.
> the rules exist.  either a veto is valid and the item being
> vetoed must submit, or it is *not* valid and the vetoer
> is the one who must submit.  it is up to the community to
> enforce these rules, either through peer pressure or possibly
> the extreme step of suspension of privileges.
> according to the structure of the foundation, it would be
> reasonable to bring cases like this to the pmc for a decision.
> if none is forthcoming, the chair of the pmc, who is the
> officer of the foundation in charge of the project, may make
> a determination.  failing that, the issue could be brought
> to the board, which is the final authority.  even that is
> not completely final, since members can elect different directors
> and re-raise the issue.  such an occurrence would be a severe
> pathology, however.
> > > no.  a veto may not be overridden.  that is fundamental.
> >
> > What about rules for revolutionaries?
> what about them?  that was a proposal written by one person and
> partially adopted by one project.  it is not asf policy, though
> it is an implementation of the basic how-to-deal-with-a-veto
> rules.  an implementation which provides support from the
> project structure.  valuable experience has been gained from
> its application, even if not everyone agrees on the conclusions.
> > It's quite easy to block (r)evolution by vetoes
> technically valid vetos?
> > > commit access is a privilege, not a right.  if someone uses
> > > vetos capriciously -- or ignores them -- despite warnings,
> > > the suspension or revocation of commit privileges should
> > > definitely be considered as an option.
> >
> > Again, *who* decides it?
> > *Who* can propose it?
> > *How* should it be voted?
> ultimately, the foundation officer in charge of the project.
> who, as i said, will probably work frantically to keep it
> from landing in its lap, and will try to come to some pathway
> that is best for and most acceptable to the community.
> what follows is my opinion, based on intimate experience.  i
> believe it to be an accurate portrayal of reality.  i could be
> mistaken, and i hope roy and others will correct me if so.
> > But it still smells like benevolent dictatorship...
> in a way it is.  be very clear on this.  it is not a demoncracy.
> there is a very definite structure of authority and responsibility.
> the code belongs to the foundation.  the foundation is the
> members.  the members elect the board to oversee the foundation
> and ensure its continued existence and health.  the board appoints
> officers to oversee and be responsible for projects.  these officers
> are ex officio chairs of the projects' management committees.
> beyond that point, the structure becomes more diverse on a
> project-by-project basis, since how each pmc will 'manage' its
> project is something it and the chair will develop that, in
> their opinions, is best for the project and the community.
> it is a balancing effort.  the only rights here are those invested
> in the members, who comprise the foundation.  the board serves
> at the pleasure of the members; the pmcs serve at the pleasure
> of the board.  that is the top-down authoritarian legal view.
> balanced against that is that the only way the foundation will
> continue and succeed is by having healthy communities; healthy
> communities mean committers who are [mostly] content.  which
> means that the board and the pmcs can only fulfill their functions
> by supporting the committers.  the factors of 'contentment' include
> (but are not necessarily limited to) 'let me work on the code without
> joggling my elbow,' 'provide me the tools and infrastructure i need
> to work on the code,' and 'provide me an environment of peers in
> which i can have fun.'  therefore, the foundation guidelines -- and
> each projects' -- are (or should be) geared to satisfy these needs
> in the most constructive (or least destructive) way that can be
> devised.
> <digression>
> which raises another interesting point.  i think no-one will
> dispute that there are people who are better qualified than
> others to do <random technical magic>.  however, when it comes
> to figuring out how to make lots of people 'play nice' and
> constructively together, it seems everyone considers itself
> an expert.
> well, not everyone.  some people, myself included, recognise
> that as a talent or acquired skill, and, deep down, realise that
> there are people better qualified in that area than ourselves --
> even if we have difficulty admitting it publicly or even to
> ourselves.
> </digression>
> i think what has been missing here is not the structure, but
> *awareness* of it and its significance.
> okey, i've sounded off on my opinion enough, i think.  i'll
> go don my asbestos environment suit now.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


Peter Donald
Money is how people with no talent keep score.

View raw message