On 2/29/2012 8:59 AM, André Malo wrote:
> On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote:
>>
>> I withdraw this vote, reverting my position to -1, until collaboration and
>> respect for options and insights of fellow committers as well as project
>> decisions and votes can be consistently demonstrated.
>
> I always thought, you'd have to provide technical reasons for -1 votes (?).
Let's take Roy's position on the attached vote discussion, it's relevant.
These new modules are certainly additions/deletions to httpd.
It is crystal clear that a veto is valid. It is incumbent upon the coder
who makes a proposal to overcome objections. In this previous vote, some
dozen developers failed to make that case to Graham, and his veto stood.
Now Graham comes to the project with three modules and a hope that
"this isn't a "code dump", my intention is to continue to develop and
support this moving forward, and hopefully expand the community around them."
He said the same thing about completing the LDAP abstraction half a decade ago
or more. Attempts to route around his failure were unsuccessful because of
his obstructionism. We are at a design impass with the community blocked on
some handwave and a commitment to redesign an api someday, but likely never.
Nothing can be allowed in core on some "hope" of expanding a community.
Either there is collaboration and the code belongs at httpd, or there is
not collaboration and the code does not. There are sandboxes and there
are subprojects to begin that justification. Graham was offered that
resolution which HE originally proposed, and for two months, has refused
to act or acknowledge the demand that he revert his misfiled contribution.
My veto to all three modules stands. If three committers with track records
of collaboration (meaning most everyone else here) step up with +1 votes that
includes their commitment to review and maintain one of these modules, seek
the software license grant, and to file the ip-clearance with general@incubator,
I'm willing to relax my veto on creating that subproject. But not into a core
module until the subproject is successful.
--- Begin Message ---
On Jul 12, 2011, at 8:20 AM, Joe Orton wrote:
> On Sun, Jul 10, 2011 at 03:34:10PM -0700, Roy T. Fielding wrote:
>> Regardless of anyone else's opinion, the addition or deletion of a
>> new API to our product is a technical change that can be vetoed.
>> Likewise, the API being an incomplete abstraction that isn't
>> needed in httpd is a valid technical reason to veto it even if
>> it had once been in apr-util.
>>
>> Other than the convoluted history of this particular argument,
>> I don't see any reason for further frustration. Revert the commit.
>
> Yet again: if the objection is to extending the exported mod_ldap API,
> that objection can be resolved without wholesale revert; most of the
> stuff added does not need to be exposed in the API, it was just done for
> consistency.
The objection can only be resolved by convincing the person who has
objected to change *their* opinion or by removing the thing being
objected to. The time for convincing has expired -- let's move on.
> I do not understand using "incomplete abstraction" as motivation for
> veto, because mod_ldap's API was already an incomplete abstraction. If
> this was OK before, it is not reason for veto now.
The API was moved to *this* project and all of the names were changed.
It is, effectively, a new public API for this project.
> We are doomed to revisit this argument time and again if we avoid
> actually discussing the technical issues.
The whole point of having a set of voting guidelines is to avoid
having a discussion about process which is colored by the particular
issue being discussed and to avoid having discussions about
technical issues which become poisoned because of perceived unfairness
in the way people's opinions are being respected.
Remove the process issue first and then the technical issues can be
resolved one at a time as technical issues.
....Roy
--- End Message ---
