incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject Re: veto stuff (was: Code ownership)
Date Thu, 07 Nov 2002 01:51:47 GMT

Greg Stein wrote:

>On Thu, Nov 07, 2002 at 12:32:14AM +0100, Stephen McConnell wrote:
>>B. W. Fitzpatrick wrote:
>>>Peter Donald <> writes:
>>>>of course. I had to revert vetoed changes from the same
>>>>committer. Kool - huh!
>>>Extremely disturbing.
>>Wow - "extremely disturbing" - that cause for concern. Let's go out and 
>>nail the poor unfortunate to a cross.  Verify the facts?  Forget it - 
>>lets get on with a good old fashioned crusifiction.
>Of course it is disturbing. One of:
>1) Fitz is (rightfully) assuming that people are speaking truthfully, or at
>   least without willful deception. Therefore, based on Peter's words, there
>   was some ugly stuff going on.
>2) Peter is lying or willfully deceiving. Also disturbing.
>(there's various shades of grey between those, but hey)
>In any case, this *has* veered from the original topic, but this is exactly
>the kind of case that the Incubator is supposed to solve.
>So. Let's clear the air here. To be *VERY* explicit, there is a lot of bad
>blood (in the past?) between Peter and Steve. 

However, it is only my speculation that Pete is making a vailed 
referenced to myself.  We have nothing to go on except that a sin has 
been committed.  If we pile up a multitude of sins, then surely the 
sinner will published. Yes, we can go down the track of a public review 
of the issue that Pete has raised - will it solve anything - I doubt it. 
 What it will do is simply raise questions concerning the integrigy of 
Pete verus Steve.  That's a zero win proposition.  Instead - should this 
be focussed on the *real* issue, the policies and procedures under which 
disputes can be resolved without necessity for the type of actions we 
seeing here.

Let's look for a moment at the dispute resolution failure:

  1. no definative dispute resolution framework

      * Pete has claims against me and I have claims agains Pete
      * Jakarta PMC cannot reolve the issue because they are not part of 
the process
      * the project committers are not ready or willing to align with 
either Pete or I
      * the Jakarta produres are at least vauge when it comes to veto 
And its the last point that is the real isuse here.  

Neither Pete nor I have a mechanism under the Jakarta rules to close our 
differences one way or the other.  This gives Pete the license to persue 
"issue dropping" across public forums without recourse, and in turn, 
this gives me the right to the persure the truth.  Keep in mind that I'm 
fighting for every other Apache committer that has experienced the rath 
of Pete - and every other committer that has experienced procedural 
abuse - simply because the procedures for closure don't exist.  More 
importantly, I'm fighting for a better Apache - an Apache where issue 
like this can be resolved without recorse to personal attacks.

If we look at the current Jakarta procedures:

    > "No." On issues where consensus is required, this vote counts
    > as a veto. All vetos must contain an explanation of why the veto
    > is appropriate. Vetos with no explanation are void. No veto can
    > be overruled. If you disagree with the veto, you should lobby the
    > person who cast the veto. Voters intending to veto an action item
    > should make their opinions known to the group immediately so that
    > the problem can be remedied as early as possible.

Ok, so if I'm the subject of a veto that I consider is invalid on that 
grounds that no rational justification was provided, what should one do 
to resolve the situation.  According to Jakarta law the rationale "my 
girfriend has a headache" is a rationale - but is it an acceptable 
rationale?  As soon as you enter a situation where a veto is irrationale 
- your in undefined territory.

If this thread can leverage the sequence of the dispute between Pete and 
myself (or anyone else), then this thread will be a valuable contributution.

>No problem, that was in the
>past. However, Peter has brought this up in at least two forums over the
>past couple months, so it isn't any longer "just in the past." So let's
>figure out the specifics and put this to rest.
>Peter or Steve: can you identify the veto(es) in question? Or the time frame
>so we can search for them? And the related commits. Specifically, which
>commit was vetoed, and the reason for the veto? What was the sequence of
>events after that?

I'm going to have to leave the veto question to Pete - after all Pete 
has raised an accusation against someone - and I'm don't know if this 
particular instance is anything to do with myself or not - but I have a 
sneaking suspision :-).  If it was anything to do with containerkit, 
then I have to confess that following the fork or containerkit (no 
basically dead), together with what I admit were certain emails 
referencing things that one does not do in front of one' mother - well, 
its reasonable to say that things deteriated.

  This is a independent email that summarises that status of affairs as 
of July 2002
  and Pete's liberal reply ... -1s sprinked within
  but suppliemented with more fleshing out of the real requirements
  leading to a fork base on private emails that made it clear that
  collaboration was out of scope
  which raised immediately discussion of solutions and the need for 

But all of this is academic - for the real battle, you need to go to the 
CVS achives and the subsequent battles concerning the Phoenix project 
and commits dealing with opening up the Phoenix model to deal with 
non-Pheonix specific components.  Then after that, you need to go into 
the battle concerning "Cornerstone" - apparently a set of "Avalon" 
componets that were are in effect "Phoenix" components, and the attempts 
to eliminate container depedencies.  And following on from that is a 
mediation process as stuff stared to fly around (refer PMC email in 
response to Pete's claim of Avalon indescretions).  Changes to 
Cornerstone were introcuced that broke James compatibility, but the war 
was on and James didn't really matter - it was much more a question of 
maintaining a position.  

At the end of the day - I don't think you can say draw a line and say 
that Pete was right or that Steve was right.  I *do* think you can draw 
a line an say that the structure was not in place to resolve the issue.  

>Something is incorrect, and I would hope that the Incubator can identify it
>and use it as a case study for how things "should" happen or not. e.g. what
>is the proper procedure for vetoes? How should they be resolved? What should
>happen in the code base? etc.

This *is* the issue.

Pete and I will continue to be each other anti-christ for the forseable 
future - but in the meantime, the real value that will come out of this 
is mechanisms through which conflicts can be resolved - not based on 
"who you know", but based on the "merit of the case", and the "facts".

If we look into the incubator description of a voting process, what 
happens if a veto is irrationale or or inconsitent? It's not documeted - 
at least in the proposed revisions for the jakarta prcedures there was a 
requement for veto endorcement by at least one other committer in a case 
of a dispute - in addition, it references the PMC as an ultimate 
authority.  These things must be addressed because they represent the 
foundation of Apache - and that's something worth investing time and 
effort in.

To that end, I'm ready to work on a description of process for dispute 

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

View raw message