httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Technical reasons for -1 votes (?)
Date Thu, 01 Mar 2012 17:20:22 GMT
On 2/29/2012 6:25 PM, Roy T. Fielding wrote:
> On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote:
>> Let's take Roy's position on the attached vote discussion, it's relevant.
>> These new modules are certainly additions/deletions to httpd.
> Yes, but they are modules.  Hence, their mere existence in our tree
> is not a technical reason to exclude them.  We have a modular architecture
> so that people who don't want a module don't have to build it.  In fact,
> it was exactly this type of argument in 1995 that caused rst to focus
> on creating a modular architecture.

Ok, so to clarify, you are reversing your answer to Joe?  The LDAP changes
were a change to a module.  Not an httpd-wide API, just a module.  So you
are saying that your comment to Joe, "The API was moved to *this* project
and all of the names were changed.  It is, effectively, a new public API
for this project." was a misinformed statement (as it moved the ldap code
into mod_ldap and not into the core API).  That veto was unjustified?

Or rather, had we not exported a single symbol, then the veto was unjustified?

> If there were dependencies or license conditions brought in that somehow
> harmed the server without the module being active, then that would be a
> technical objection.

There was no such case for the ldap change, so you are saying that specific
veto was unjustified, right?  Anyways, all of this is distraction, let's
drill in further to your analysis;

> Traditionally, we have allowed any module that has at least one willing
> volunteer committer to maintain it.  And I agree with Jim, none of the
> subprojects have been as successful as just placing the code in the
> main tree.

Allowed it by... voting to accept it, right?  I accept that all of my
colleagues have different rationals for their +/- votes.  Right now, just
about 3% of the committee are willing to entertain these module additions
to httpd trunk and 1.5% are against adding these to trunk.  I chalk this
up to burnout, 2.4 was very complex to release and people know their +1
votes are commitments and alter the httpd tarball for better or worse.

As Jim points out, "The fact is that once a project lives under the main
tree, it's part of our shared project" is dead to right.  Jim alone is
voting with minfrin to support these living in that shared tree, and only
I vote that we don't, at this time, until there are more committers who
are willing to share Jim's position.

If there was a vote to add this module to core, that would be lovely, we
could vote on it.  Sadly, minfrin offered no such vote, and whatever your
conclusion on the 'better course' - it was not voted on, and you hadn't
expressed a vote to adopt it in either case.

> I have no idea why mod_fcgi is in a subproject.  mod_ftp is there
> because it isn't an HTTP server.  mod_aspdotnet had all sorts of
> licensing issues that I never quite figured out.

Nonsequitor, if we want to launch into a discussion of subprojects vs.
modules, that's great.  That wasn't the conversation minfrin started,
and that's why I have a VETO on the commit.  Correct the mis-execution
by conforming to the vote he held, or correct the vote instead.  I've
VETOED a commit which is something other than what was voted on because
the project did not consent to his action.

If there are two other committers who will vote with Jim for this
project to accept one or more of these modules into trunk (rather than
subproject), and someone will finish the ip-clearance, I'm great with
that.  If none of that happens I will revert this mess.

> I see no reason not to commit mod_firehose, though I haven't had a
> chance to look at the code myself.  

mod_firehose is already [erroniously] committed without ip-clearance.
Only Jim agrees with minfrin that it belongs in trunk.  If YOU want to
vote for it to be in trunk, do that.  So far, it was accepted by this
project only as an additional subproject.

Only you and Jim are defending this addition without ip-clearance.
Perhaps you are signing up to do that ip-clearance, since it doesn't
seem to be coming from the committer.

I've voted against mod_policy and mod_combine until this mess is resolved.
With sufficient +1's I would have withdrawn all objections, but right now
I smell a code dump, and see nobody but Jim disagreeing with me.

> Nor am I willing to respect a veto war based on the impact of past vetos.

No, it's not a veto war.  Only Jim has volunteered to maintain this code
(or agreed to help minfrin do so).  Right now minfrin blocks correcting
mod_ldap, insists it's his project to finish his way, which hurts this
project. So his assurance that he should "my intention is to continue to
develop and support this" rings hollow.  That is the ONLY relationship
to the other veto I had quoted your opinion on, other than to point out
that vetos are legitimate.  Any assurance that he should be a sole
maintainer of not one but three+ more httpd module additions seems foolish.

> Now, if you'll excuse me, I have at least two other walls to bang
> my head on today ...

Enjoy, I could certainly be wasting my time on better things as well.
Unfortunately httpd got to its pre-2.4 state because there are so few
committers who are actually reviewing one another's contributions.
Throwing gunk into trunk doesn't help prevent it from happening again.

Perhaps the threat of releasing 2.6 / 3.0 this coming November might
keep trunk from atrophying into a similar state, once again?

View raw message