[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: Technical reasons for -1 votes (?)
From:       Jim Jagielski <jim () jaguNET ! com>
Date:       2012-02-29 20:15:00
Message-ID: BEA9D208-BF08-4B58-BF0D-5B8640E3C284 () jaguNET ! com
[Download RAW message or body]

Wow...

As far as I can tell, we have *never* been so tight arsed with
anything else: not mod_proxy_html, mod_sed, mod_rewrite,
mod_dumpio, mod_substitute, (add your favorite one here)...
And especially not with someone who's been a PMC member for
as long as Graham has (~10yrs).

I reiterate my +1s for accepting the code and stress that my
preference is right in the main tree.

On Feb 29, 2012, at 12:42 PM, William A. Rowe Jr. wrote:

> 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.
> 
> <Attached Message.eml>

[prev in list] [next in list] [prev in thread] [next in thread]