httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r1215525 - in /httpd/httpd/trunk: ./ docs/manual/mod/ docs/manual/programs/ modules/debugging/ support/
Date Tue, 20 Dec 2011 18:53:49 GMT
> On Dec 18, 2011, at 11:45 AM, Graham Leggett wrote:
>>
>> Given that mod_firehose is significantly simpler than mod_policy, I am struggling
to understand given both your stated preference above, and the preferences of others already
stated, why suddenly this is a big issue.

Simpler?  Far more files are touched.  10 commits to inject it.  A new
support utility must be maintained by the project.  It introduces a new
nonstandard data format.  And the module name is not descriptive, which
is a no-no for httpd core, as far as I'm concerned.

mod_policy was a single .c file, right?  It doesn't require a support
binary to function, right?  (Naming it mod_http_policy might be clearer).
Single commit, plus regen of the docs.  I'm struggling to understand what
you mean by less simple.

On 12/18/2011 11:31 AM, Jim Jagielski wrote:
> FWIW, my vote also applies to incorping direct into httpd repo...
> It was not "conditional" on it being a "subproject"

Thanks Jim!

mod_firehose had still needed one more vote if it was to become part
of trunk.  It now needs two...

-1 to this commit.  I'm casting this as a vote, and expressly not vetoing
the change; *provided it obtains a majority +2 committers who will truly
review the design and the code*.  (3 +1's are always needed; 4 +1/my -1
passes for "accepted" as far as I'm concerned).

My preference for it remains to be a subproject, and the name rethought
(we have all functional module names in httpd), so that people can start
adopting it and proving it *before* we inject it into 2.4 branch.
It would be a shame for it to grow stale for 2-5 years, but the 2.3-dev
process reflects that not enough committers are active right now to
ensure newly introduced code is sufficiently thought through.

Also wondering about the choice of compiling the firehose support tool
instead of authoring something trivially maintainable in perl or python.
That's what we did for mod_log_forensic.  Better yet, if it were using
a standard representation, there isn't much need for the 'firehose'
support utility to be maintained here.

I won't trust your code to receive adequate review sitting out on trunk
for backport... we don't need to dwell on your previous poor designs
such as r59099... still not corrected by you after 7 years... and still
blocked by your veto for adequate resolution in httpd 2.4.  Anything
you design that implies introduction of an API or a data representation
format is suspect until proven otherwise; particularly in light of your
failure to reasonably collaborate on implementation details.

A subproject would give this new code the attention it deserves while
enabling users, and I'll even go so far as to +1 it's introduction as
a subproject, apart from httpd trunk, where it can float or sink on
its own merits.

Igor and Jim both agreed with you to adopt mod_combine as a subproject,
so all three modules have green lights as such; only one was green lit
for trunk.  Please don't repeat this mistake of jamming mod_combine
into trunk, just yet?  Put it to a vote (or let voters refine their +1
to indicate that it belongs in trunk).


Mime
View raw message