Graham,
After two months, firehose still didn't obtain another +1, so the vote to
incorporate firehose into trunk stands at 3 +1's, 1 -1, and therefore
failed the vote for inclusion in trunk.
There are 4 +1's for a firehose subproject at httpd. If you wish to continue
this effort you can keep this simple by svn mv'ing those respective files across
from httpd/httpd/trunk to httpd/mod_firehose/trunk, where it can build a larger
community within httpd project, and things like the data representation format
can be evaluated and enhanced by the community.
I would be happy to entertain merging this to trunk once we have contribution
from multiple individuals to the subproject and the consensus is that it will
be supported by the entire community in 2.6. As an example, only Jeff and I
have recently made any significant commits to the mod_fcgid, so by my own
standards it is still missing at least one more active committer before
mod_fcgid could be considered for inclusion trunk.
FWIW my support to explore a mod_combine subproject is attached, and I'll
clarify that I meant to +1 the subproject, -1 for commit to trunk as a
module (Jim voted +1 to either case) so there are now three votes for a
mod_combine subproject, if you want to proceed with that effort as well.
Yours,
Bill
On 12/20/2011 12:53 PM, William A. Rowe Jr. wrote:
>> 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).
--- Begin Message ---
I haven't had time to study this idea in detail, but it does sound much
more like a subproject, as opposed to incorporating as a module.
I'm not very clear how this differs in approach from mod_pagespeed, and
how the two could be leveraged together.
--- End Message ---
