You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2011/12/13 17:22:13 UTC
Proposal: adoption of mod_policy subproject
Hi all,
As with mod_firehose, I have concluded negotiation with the BBC to open source some httpd modules that I wrote under the AL, and the BBC have very kindly agreed to donate the code to the ASF[1], which I believe would fit well as a subproject of httpd, and would like to know whether httpd would accept these.
To be clear, 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.
- mod_policy: "HTTP protocol police"
One of the curses of developing restful services is that clients are "liberal in what they accept". This leads many developers of restful services to be "liberal in what they send", resulting in a service that works for the developer, but fails under load or other real world conditions.
mod_policy is a set of httpd filters that detect and implement a set of HTTP protocol checks, the idea being you declare a policy for your development and testing environments, and requests/responses that violate the policy will either log a warning to the error_log or explicitly fail with a suitable error message, clearly telling the developer what they have done wrong, with the expectation that the developer fixes this before the code sees production.
The set of policies to apply is as follows, but is expected to change with time:
o Content-Type: check that it's present and valid
o Content-Length: check that it is present and valid (used to ensure that keepalive requests between httpd and load balancers aren't prematurely terminated by a Connection: close)
o Keepalive: more detailed keepalive checks
o Vary: headers like User-Agent represent a potential caching DoS, if specified header is present in Vary, fail
o Validation: if ETag/Last-Modified not present, fail
o Conditional: if a conditional request doesn't comes back with a properly compliant conditional response, fail
o No-cache: if the response is declared no cache, fail
o Max-age: if the response has a max-age less than a given threshold, fail
o Version: if the request was less than a given version (< HTTP1/1, for example) fail
These are an initial set of policies that were created to meet current needs at the time of development, however it is expected this list will grow with time. mod_policy would benefit greatly from the experience of the authorities on HTTP that exist here, with the above policies being tightened up and improved.
With the proliferation of restful services out there in various states of dubious protocol compliance, this set of filters can be a huge help to stop developers doing non compliant things, while not getting in the way of production code. The filters also help enforce that content remains cacheable, which for sites that endure high loads or thundering herds is important.
The code is currently packaged as an RPM, wrapped in autotools, and a snapshot is available here:
http://people.apache.org/~minfrin/bbc-donated/mod_policy/
The corresponding README documenting in more detail is here:
http://people.apache.org/~minfrin/bbc-donated/mod_policy/README
The code itself is here:
http://people.apache.org/~minfrin/bbc-donated/mod_policy/mod_policy.c
Obviously the expectation is for the documentation to be completed and fleshed out.
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322
Regards,
Graham
--
Re: Proposal: adoption of mod_policy subproject
Posted by Graham Leggett <mi...@sharp.fm>.
On 13 Dec 2011, at 8:39 PM, William A. Rowe Jr. wrote:
>> The set of policies to apply is as follows, but is expected to change with time:
>>
>> o Content-Type: check that it's present and valid
>> o Content-Length: check that it is present and valid (used to ensure that keepalive requests between httpd and load balancers aren't prematurely terminated by a Connection: close)
>
> Presume this means C-L and/or T-E chunked?
The content length filter just does a simple check for content length, while the keepalive filter takes into account T/E chunked in far more detail.
What we've discovered is that our restful service layer was receiving a lot of HTTP/1.0 requests from client libraries (not entirely sure why, seems HTTP/1.0 is the default request version for some well used HTTP client libraries out there). If your service leaves off content length, and the client is HTTP/1.0, then the server indicates the end of the request by terminating the connection, which in turn makes the load balancers less effective than they should have been. We started with complaining about keepalive, and then switching to complaining about content-length so that HTTP/1.0 requests were taken into account.
Regards,
Graham
--
Re: Proposal: adoption of mod_policy subproject
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sat, 3 Mar 2012, Rainer Jung wrote:
> On 03.03.2012 15:22, Eric Covener wrote:
>>>> But it would have to be clear that inclusion into trunk would not by
>>>> default mean that they would be included in the next major release.
>>>>
>>>> Especially for mod_ftp, I think that it requires many more eyeballs
>>>> and a comprehensive test suite before it should be part of a stable
>>>> release. Otherewise, it would just be a source of lots of security
>>>> issues that need to be handled and would tie up resources.
>>>>
>>>
>>> Including into trunk, and with 2.4 RTC, then the above is all
>>> assumed...
>>
>> I think Stefan's legitimate concern is implicit inclusion in 2.6/3.0,
>> not a potential backport into 2.4.
>
> Yes, I think that's what he meant.
>
> IMHO that wasn't a problem lately. When we got closer to 2.4 several pieces
> were removed, because they were not well tested, not well-documented or
> didn't work. Determining the stuff to remove from the release wasn't a
> difficult or controversial discussion. So I'd say no further hard rules on
> which additions to trunk will make it into a further release are needed.
Yes, I was concerned about 2.6/3.0. But if other people think it won't be
a problem, then that's ok with me, too.
Re: Proposal: adoption of mod_policy subproject
Posted by Rainer Jung <ra...@kippdata.de>.
On 03.03.2012 15:22, Eric Covener wrote:
>>> But it would have to be clear that inclusion into trunk would not by
>>> default mean that they would be included in the next major release.
>>>
>>> Especially for mod_ftp, I think that it requires many more eyeballs
>>> and a comprehensive test suite before it should be part of a stable
>>> release. Otherewise, it would just be a source of lots of security
>>> issues that need to be handled and would tie up resources.
>>>
>>
>> Including into trunk, and with 2.4 RTC, then the above is all
>> assumed...
>
> I think Stefan's legitimate concern is implicit inclusion in 2.6/3.0,
> not a potential backport into 2.4.
Yes, I think that's what he meant.
IMHO that wasn't a problem lately. When we got closer to 2.4 several
pieces were removed, because they were not well tested, not
well-documented or didn't work. Determining the stuff to remove from the
release wasn't a difficult or controversial discussion. So I'd say no
further hard rules on which additions to trunk will make it into a
further release are needed.
Regards,
Rainer
Re: Proposal: adoption of mod_policy subproject
Posted by Eric Covener <co...@gmail.com>.
>> But it would have to be clear that inclusion into trunk would not by
>> default mean that they would be included in the next major release.
>>
>> Especially for mod_ftp, I think that it requires many more eyeballs
>> and a comprehensive test suite before it should be part of a stable
>> release. Otherewise, it would just be a source of lots of security
>> issues that need to be handled and would tie up resources.
>>
>
> Including into trunk, and with 2.4 RTC, then the above is all
> assumed...
I think Stefan's legitimate concern is implicit inclusion in 2.6/3.0,
not a potential backport into 2.4.
--
Eric Covener
covener@gmail.com
Re: Proposal: adoption of mod_policy subproject
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 2, 2012, at 2:50 PM, Stefan Fritsch wrote:
> On Wednesday 29 February 2012, Jim Jagielski wrote:
>> On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote:
>>> It's the reason why mod_aspdotnet was ejected, and why mod_arm4,
>>> mod_ftp and perhaps even mod_fcgid are all on their way out of
>>> the project as it is, unless more committers participate in
>>> those subprojects.
>>
>> The other way to approach it is to simply move them *into* the main
>> project, and not as "subprojects"...
>>
>> We've seen that subprojects do NOT work. There is more activity
>> when they are in the main tree. With the exception of mod_arm4
>> (which I've never looked at), I would be MORE than comfy having
>> both mod_ftp and mod_fcgid moved into the main tree today.
>
> But it would have to be clear that inclusion into trunk would not by
> default mean that they would be included in the next major release.
>
> Especially for mod_ftp, I think that it requires many more eyeballs
> and a comprehensive test suite before it should be part of a stable
> release. Otherewise, it would just be a source of lots of security
> issues that need to be handled and would tie up resources.
>
Including into trunk, and with 2.4 RTC, then the above is all
assumed...
Re: Proposal: adoption of mod_policy subproject
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 29 February 2012, Jim Jagielski wrote:
> On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote:
> > It's the reason why mod_aspdotnet was ejected, and why mod_arm4,
> > mod_ftp and perhaps even mod_fcgid are all on their way out of
> > the project as it is, unless more committers participate in
> > those subprojects.
>
> The other way to approach it is to simply move them *into* the main
> project, and not as "subprojects"...
>
> We've seen that subprojects do NOT work. There is more activity
> when they are in the main tree. With the exception of mod_arm4
> (which I've never looked at), I would be MORE than comfy having
> both mod_ftp and mod_fcgid moved into the main tree today.
But it would have to be clear that inclusion into trunk would not by
default mean that they would be included in the next major release.
Especially for mod_ftp, I think that it requires many more eyeballs
and a comprehensive test suite before it should be part of a stable
release. Otherewise, it would just be a source of lots of security
issues that need to be handled and would tie up resources.
Re: Proposal: adoption of mod_policy subproject
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Feb 29, 2012, at 12:19 PM, William A. Rowe Jr. wrote:
> On 2/29/2012 9:45 AM, Jim Jagielski wrote:
>>
>> On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote:
>>
>>> It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and
>>> perhaps even mod_fcgid are all on their way out of the project as it is, unless
>>> more committers participate in those subprojects.
>>
>> The other way to approach it is to simply move them *into* the main
>> project, and not as "subprojects"...
>
> Jim, I respectfully, but profoundly disagree. To have one or fewer
> active maintainers of a given module in the core distribution is far
> more problematic than having a stale subproject. The stale subproject
> cries out for attention if users or developers want to make a release.
> The core module languishes and impacts more and more users, and the
> very reputation of this project.
mod_rewrite was an "external" subproject. I submit that it is
doing better here, under the main tree.
mod_proxy_html was the same. It is under the main.
mod_sed... ditto
mod_proxy was a subproject, but lives and thrives under the main.
You mention that some modules aren't doing well. The ones you
mention do not live under the main.
The fact is that once a project lives under the main tree,
it's part of our shared project...
Re: Proposal: adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/29/2012 9:45 AM, Jim Jagielski wrote:
>
> On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote:
>
>> It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and
>> perhaps even mod_fcgid are all on their way out of the project as it is, unless
>> more committers participate in those subprojects.
>
> The other way to approach it is to simply move them *into* the main
> project, and not as "subprojects"...
Jim, I respectfully, but profoundly disagree. To have one or fewer
active maintainers of a given module in the core distribution is far
more problematic than having a stale subproject. The stale subproject
cries out for attention if users or developers want to make a release.
The core module languishes and impacts more and more users, and the
very reputation of this project.
> We've seen that subprojects do NOT work. There is more activity
> when they are in the main tree. With the exception of mod_arm4 (which
> I've never looked at), I would be MORE than comfy having both mod_ftp
> and mod_fcgid moved into the main tree today.
First you've made a blind assertion. Please document how subprojects
do not work, so we can get on the same page?
If ftp/fcgid should be in trunk (and I'm very, very close to agreeing
with you) it is only *because* they lived seperate and distinct lives
and have reached some level of collaboration and maturity. You and
I and several bugzilla contributors have offered fixes to mod_ftp.
Jeff and I and several bugzilla contributors have offered fixes to
mod_fcgid. Small but measurable communities of contributors.
What is proposed here is for mod_policy and two others to be blindly
dropped into httpd trunk without contributors, no oversight, not even
ip clearance. You and I aren't likely to come to agreement on this.
That isn't how we are supposed to work. Therefore I'm -1 altogether
to accepting any of these three contributions until minfrin demonstrates
collaboration, apologizes for wasting an incredible amount of many of
his colleagues' hours over the whole ldap mess of his creation, and now
apologizes for either misinterpreting or misrepresenting the votes cast
for these subprojects. If he had any credibility, I'd be immediately
supportive of three subprojects, where he could prove his ability to
both collaborate and find development support for these creations. Any
other outcome is yet another code dump.
Re: Proposal: adoption of mod_policy subproject
Posted by Igor Galić <i....@brainsware.org>.
+1
----- Original Message -----
>
> On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote:
>
> >
> >
> > It's the reason why mod_aspdotnet was ejected, and why mod_arm4,
> > mod_ftp and
> > perhaps even mod_fcgid are all on their way out of the project as
> > it is, unless
> > more committers participate in those subprojects.
> >
>
> The other way to approach it is to simply move them *into* the main
> project, and not as "subprojects"...
>
> We've seen that subprojects do NOT work. There is more activity
> when they are in the main tree. With the exception of mod_arm4 (which
> I've never looked at), I would be MORE than comfy having both mod_ftp
> and mod_fcgid moved into the main tree today.
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Proposal: adoption of mod_policy subproject
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Feb 29, 2012, at 10:32 AM, William A. Rowe Jr. wrote:
>
>
> It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and
> perhaps even mod_fcgid are all on their way out of the project as it is, unless
> more committers participate in those subprojects.
>
The other way to approach it is to simply move them *into* the main
project, and not as "subprojects"...
We've seen that subprojects do NOT work. There is more activity
when they are in the main tree. With the exception of mod_arm4 (which
I've never looked at), I would be MORE than comfy having both mod_ftp
and mod_fcgid moved into the main tree today.
Re: Proposal: adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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 (?).
No, only for a veto. My technical reason for this vote, although I don't need
one, is that Jim is the only other person voting +1 for mod_policy. Technical
conclusion is that if there are no developers voting +1, there are no developers
committed to maintaining this code alongside minfrin and jim.
Which is to say, I withdraw my offer to collaborate or even review this code
based on minfrin's absolute inability to collaborate with a committee, as he
had evidenced in the ldap code dump, and now in a module dump that he forgot
to hold a vote. He had 2 months to revert the firehose mis-commit, he failed.
This keeps me from work I need to be doing because I'm chasing out code dumps
from httpd. Stupid.
This leaves him with a single collaborator? 1-2 man shows aren't encouraged,
and never acceptable in core repos/asf/httpd/httpd/. No more votes +1 shows
there is no community behind these submissions, but we have subprojects and
sandboxes to offer ideas the runway to attract collaborators and a community.
It's the reason why mod_aspdotnet was ejected, and why mod_arm4, mod_ftp and
perhaps even mod_fcgid are all on their way out of the project as it is, unless
more committers participate in those subprojects.
Putting more code dumps into core httpd is not going to help create communities,
and it proves to be a major obstacle to getting any major.minor release out the
door when we get around to noticing that code was never reviewed on the way in.
Would I have anything to post if there were 10 +1's to accept minfrin's new
modules? Of course not. But as it stands, there are not 10 +1's, so there is
not sufficient trust in his submission to mainline it straight to core.
Re: Technical reasons for -1 votes (?)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/1/2012 4:17 PM, Roy T. Fielding wrote:
> On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:
>
>> Or rather, had we not exported a single symbol, then the veto was unjustified?
>
> I don't remember the details, but it was presented by you as a new API.
> It was described by you as the addition of new LDAP libraries to
> httpd. And it was most certainly a change to the existing code in
> mod_ldap.
Roy, I'm sorry. Obviously I miscommunicated. It was a former API.
The proposal was to fold that behavior into a single self-contained
module. I will present this in the coming month in a manner that
conforms to your understanding of a "module" vs. an "API", such that
no individual can veto it, and the dozen+ of us can vote for it and
be forever rid of the garbage former-API constraint, ignoring those
crazy voices from the wilderness.
> If a vote is required (i.e., anyone objects), then it is a majority vote
> with minimal quorum (three +1s), as usual.
That's the page I started on, thanks for confirming! These modules
did NOT have majorities for inclusion in trunk. Tonight, one finally
does. I never believed I had a veto, only 1 vote against blind implied
consent.
> I submit that there was confusion and the right thing to do would be to
> ask politely for the confusion to be resolved by an actual vote.
> It would help if you were not being an ass about it and randomly
> accusing people of nefarious behavior just because they don't give
> a damn about this particular difference of opinion.
>
> And it isn't Graham's responsibility to run the vote.
Ah, but you see, that's the rub. There WAS a vote. A proposal was
made by Graham, a vote was held by Graham, and a DIFFERENT course of
action was followed by Graham. Amazingly, Graham ran the successful
vote, for an altogether different outcome.
That is what is objectionable; if there is anything in the past months
demonstrates psychotic behavior, it is not my objections to what had
transpired, but what actually transpired.
Quoting the private list, where there is to be no development discussion
(so ergo these comments cannot be confidential);
On 12/8/2011 7:40 AM, Graham Leggett wrote:
> On 08 Dec 2011, at 3:30 PM, William A. Rowe Jr. wrote:
>
>> But I think we are saying the same thing... I just wanted to be
>> sure this was understood as "[poll] Potential Adoption of..." and
>> not something actually "adopted" as in your message subject.
>
> The word "proposal" means exactly that, and I haven't seen any
> misunderstanding so far from anybody.
at which point, the entire discussion went sideways once Graham adopted
the input of private@ development discussion into his next actions.
As the Chief Agent and Advocate against dev discussions happening in
private off of the dev list, I'm relying on you personally to ensure
this doesn't reoccur.
Re: IP Clearance? NAK
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 1, 2012, at 7:55 PM, William A. Rowe Jr. wrote:
> On 3/1/2012 9:49 PM, Sam Ruby wrote:
>>
>> I don't know what statement Roy is referring to, so I won't challenge
>> it directly. Instead I will ask that people work together to find out
>> what processes are right for the ASF at this point in time, even if
>> these processes are different than the ones that we used 10, 5, or
>> even just 2 years ago.
>
> In this specific case, I trust Roy to inform us if it meets the narrow
> response he received with respect to a single committer's creation on
> behalf of their employer (as we understand this submission) or if it
> has some additional considerations.
My understanding is that the author of the code in question is an
existing committer, has an iCLA on file, says he authored it, and
says he has permission from the copyright owner to contribute the code
to the ASF. He has made that statement in both the public list
(archived) and the actual commit.
That's all we need for contributions of code from committers to an
existing TLP. It can be five lines of code or five million lines of code.
We trust our committers.
I know that the incubator occasionally thinks it owns the process for
all contributions of code at Apache. I don't care. When code comes
from a source that has not yet signed a contributors agreement with
Apache, then we should have it go through Incubator to be sure that
some paperwork gets signed. But when it comes from an existing
committer who says he has permission to contribute under his own iCLA,
we already have the signed agreement on file and the contributor is
entirely responsible for the accuracy of his own statements. There
is no need for incubator to be involved. If there was any such need,
then every single commit from every contributor would need to go
through the same process.
There is no need to waste the contributor's time, nor the time of the
project chair, with useless procedural nonsense that has no value
whatsoever beyond the statements already made by the contributor.
We have several layers of contributor licensing to cover our ass, and
if for some bizarre reason that is not enough then I am absolutely
certain having another document in incubator summarizing it won't help.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: IP Clearance? NAK
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/1/2012 9:49 PM, Sam Ruby wrote:
>
> I don't know what statement Roy is referring to, so I won't challenge
> it directly. Instead I will ask that people work together to find out
> what processes are right for the ASF at this point in time, even if
> these processes are different than the ones that we used 10, 5, or
> even just 2 years ago.
In this specific case, I trust Roy to inform us if it meets the narrow
response he received with respect to a single committer's creation on
behalf of their employer (as we understand this submission) or if it
has some additional considerations.
Given that the President of the foundation hasn't objected for two
months to these code imports without IP clearance, obviously the
project is in the right. If you don't agree the committee or board
would take that up with the President.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: IP Clearance? NAK
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Mar 1, 2012 at 10:28 PM, William A. Rowe Jr. <wr...@apache.org> wrote:
> On 3/1/2012 9:08 PM, Greg Stein wrote:
>>
>> Why don't you stop with your passive-aggressive bullshit, and read the
>> thread over on legal-discuss where we talked about fixing the "short
>> form" IP Clearance process. The IP policies have not changed, but they
>> *should*, along the lines Roy suggests in that thread.
>
> Greg; Roy just stated, it's not applicable and invalid.
Please don't take a statement out of context and extrapolate from that
that a long standing policy is entirely not applicable and invalid.
If you interpret Roy's statement narrowly - i.e., that a contribution
that a committer claims is 100% their original work - needs no further
clearance, then that likely is something over which we can find
consensus.
If you interpret Roy's statement too liberally - i.e. that groups of
committers don't need to collaborate with the oversight of a PMC,
track who has contributed or who has not, or do their work using of
ASF infrastructure; for all we care they can simply reimport their
work wholesale when then wish to make an ASF release - then that is
not likely to fly.
I don't know what statement Roy is referring to, so I won't challenge
it directly. Instead I will ask that people work together to find out
what processes are right for the ASF at this point in time, even if
these processes are different than the ones that we used 10, 5, or
even just 2 years ago.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: IP Clearance? NAK
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 3/1/2012 9:08 PM, Greg Stein wrote:
>
> Why don't you stop with your passive-aggressive bullshit, and read the
> thread over on legal-discuss where we talked about fixing the "short
> form" IP Clearance process. The IP policies have not changed, but they
> *should*, along the lines Roy suggests in that thread.
Greg; Roy just stated, it's not applicable and invalid.
Ergo the project will ignore this "process" until either 1. the Legal
Committee or 2. the ASF President inform the HTTP project of specific
external steps that it must follow with respect to IP intake offered by
committers (and as proxy for their employers).
Incubator isn't actually given any jurisdiction over projects. Legal
committee is... and Roy states that Legal cleared HTTP from following
this (quoting) BULLSHIT process in respect to committer contributions.
I am getting incredibly frustrated with the fact that three founders and
current board members have no common institutional memory. You three
probably should just hang up the hats already if you can't agree for even
a single day on a recollection any particular precedent. I might be passive
aggressive some days, but I'm not a psychopathic schizophrenic as the three
headed RoyGregJim beast is.
In the meantime, there is a project to run. Roy acting as a former
officer has informed Eric, the current chair, and myself, a former chair,
of specific internal and official communication with the legal committee
that this process is not applicable to contributions from committers, and
we will respect Roy's recollection as former Chair until we hear otherwise
from an officer (not a schizo Director) of the foundation.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: IP Clearance? NAK
Posted by "William A. Rowe Jr." <wr...@apache.org>.
On 3/1/2012 9:08 PM, Greg Stein wrote:
>
> Why don't you stop with your passive-aggressive bullshit, and read the
> thread over on legal-discuss where we talked about fixing the "short
> form" IP Clearance process. The IP policies have not changed, but they
> *should*, along the lines Roy suggests in that thread.
Greg; Roy just stated, it's not applicable and invalid.
Ergo the project will ignore this "process" until either 1. the Legal
Committee or 2. the ASF President inform the HTTP project of specific
external steps that it must follow with respect to IP intake offered by
committers (and as proxy for their employers).
Incubator isn't actually given any jurisdiction over projects. Legal
committee is... and Roy states that Legal cleared HTTP from following
this (quoting) BULLSHIT process in respect to committer contributions.
I am getting incredibly frustrated with the fact that three founders and
current board members have no common institutional memory. You three
probably should just hang up the hats already if you can't agree for even
a single day on a recollection any particular precedent. I might be passive
aggressive some days, but I'm not a psychopathic schizophrenic as the three
headed RoyGregJim beast is.
In the meantime, there is a project to run. Roy acting as a former
officer has informed Eric, the current chair, and myself, a former chair,
of specific internal and official communication with the legal committee
that this process is not applicable to contributions from committers, and
we will respect Roy's recollection as former Chair until we hear otherwise
from an officer (not a schizo Director) of the foundation.
Re: IP Clearance? NAK
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Mar 1, 2012 at 20:52, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 3/1/2012 4:17 PM, Roy T. Fielding wrote:
>> On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:
>>
>>> Perhaps you are signing up to do that ip-clearance, since it doesn't
>>> seem to be coming from the committer.
>>
>> IP clearance for an existing committer is BULLSHIT. I already cleared
>> that with Legal when I was chair of this project.
>
> Somehow, having chaired the HTTP Server project for 2 years, I had missed
> the memo. This information is not being communicated. Thank you for
> enlightening me, our chair Eric, and the rest of the TLP communities.
>
> The HTTP Server Project will proceed to ignore the IP Clearance process
> laid out by the Incubator for all incoming contributions from any actual
> project committer or their employer, until informed otherwise by the
> President of the foundation.
Why don't you stop with your passive-aggressive bullshit, and read the
thread over on legal-discuss where we talked about fixing the "short
form" IP Clearance process. The IP policies have not changed, but they
*should*, along the lines Roy suggests in that thread.
The HTTP PMC cannot ignore the clearance process. But we do need to
fix the process. And we don't need your crap.
-g
Re: IP Clearance? NAK
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Mar 1, 2012 at 20:52, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 3/1/2012 4:17 PM, Roy T. Fielding wrote:
>> On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:
>>
>>> Perhaps you are signing up to do that ip-clearance, since it doesn't
>>> seem to be coming from the committer.
>>
>> IP clearance for an existing committer is BULLSHIT. I already cleared
>> that with Legal when I was chair of this project.
>
> Somehow, having chaired the HTTP Server project for 2 years, I had missed
> the memo. This information is not being communicated. Thank you for
> enlightening me, our chair Eric, and the rest of the TLP communities.
>
> The HTTP Server Project will proceed to ignore the IP Clearance process
> laid out by the Incubator for all incoming contributions from any actual
> project committer or their employer, until informed otherwise by the
> President of the foundation.
Why don't you stop with your passive-aggressive bullshit, and read the
thread over on legal-discuss where we talked about fixing the "short
form" IP Clearance process. The IP policies have not changed, but they
*should*, along the lines Roy suggests in that thread.
The HTTP PMC cannot ignore the clearance process. But we do need to
fix the process. And we don't need your crap.
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
IP Clearance? NAK
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/1/2012 4:17 PM, Roy T. Fielding wrote:
> On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:
>
>> Perhaps you are signing up to do that ip-clearance, since it doesn't
>> seem to be coming from the committer.
>
> IP clearance for an existing committer is BULLSHIT. I already cleared
> that with Legal when I was chair of this project.
Somehow, having chaired the HTTP Server project for 2 years, I had missed
the memo. This information is not being communicated. Thank you for
enlightening me, our chair Eric, and the rest of the TLP communities.
The HTTP Server Project will proceed to ignore the IP Clearance process
laid out by the Incubator for all incoming contributions from any actual
project committer or their employer, until informed otherwise by the
President of the foundation.
IP Clearance? NAK
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/1/2012 4:17 PM, Roy T. Fielding wrote:
> On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:
>
>> Perhaps you are signing up to do that ip-clearance, since it doesn't
>> seem to be coming from the committer.
>
> IP clearance for an existing committer is BULLSHIT. I already cleared
> that with Legal when I was chair of this project.
Somehow, having chaired the HTTP Server project for 2 years, I had missed
the memo. This information is not being communicated. Thank you for
enlightening me, our chair Eric, and the rest of the TLP communities.
The HTTP Server Project will proceed to ignore the IP Clearance process
laid out by the Incubator for all incoming contributions from any actual
project committer or their employer, until informed otherwise by the
President of the foundation.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Technical reasons for -1 votes (?)
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:
> 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?
I don't remember the details, but it was presented by you as a new API.
It was described by you as the addition of new LDAP libraries to
httpd. And it was most certainly a change to the existing code in
mod_ldap.
Had it been presented as a new module with a new name and optional
configuration, I would have said new modules only need one committer
to maintain and a majority vote to decide if there is any objections.
Quite frankly, I don't care either way for either change. What I care
about is continual use of procedural bullshit to justify interference
with other people scratching their own itches. If you don't like the
module, then don't use it. If it has security holes or licensing issues,
then those are grounds for a veto. If you don't like Grahams's attitude,
that's too frigging bad -- find another way to vent your frustration or
try to resolve it via the PMC, but don't mix it with a technical vote.
>> 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.
If a vote is required (i.e., anyone objects), then it is a majority vote
with minimal quorum (three +1s), as usual.
> 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 submit that there was confusion and the right thing to do would be to
ask politely for the confusion to be resolved by an actual vote.
It would help if you were not being an ass about it and randomly
accusing people of nefarious behavior just because they don't give
a damn about this particular difference of opinion.
And it isn't Graham's responsibility to run the vote.
>> 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.
You are confused. You don't need to veto a non-event -- just conduct
the vote properly and be done.
> 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.
Fine with me, if you stop blathering about it and conduct the vote
properly. You know how to conduct a vote.
>> 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.
IP clearance for an existing committer is BULLSHIT. I already cleared
that with Legal when I was chair of this project.
> 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.
That is your opinion. It counts as a -1 (non veto).
>> 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.
Equally painful, not better.
> 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.
Not throwing gunk into trunk is worse.
> Perhaps the threat of releasing 2.6 / 3.0 this coming November might
> keep trunk from atrophying into a similar state, once again?
Why wait until November?
....Roy
Re: Technical reasons for -1 votes (?)
Posted by Greg Stein <gs...@gmail.com>.
On Mar 1, 2012 12:20 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>...
> 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 support Jim. +1
Re: Technical reasons for -1 votes (?)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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?
Re: Technical reasons for -1 votes (?)
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 1, 2012, at 12:28 PM, William A. Rowe Jr. wrote:
> On 3/1/2012 1:58 PM, Jim Jagielski wrote:
>>
>> On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote:
>>
>>> On 2/29/2012 6:25 PM, Roy T. Fielding wrote:
>>>>
>>>> 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.
>>>
>>> Which explains mod_macro how, exactly?
>>
>> At this point, my head exploded Scanners-like...
>
> Funny, mine had exploded at the dis-congruity of;
>
>>>> mod_ftp is there because it isn't an HTTP server.
>
> which is apropos of what?
It is a different product. If it were changed so that it could
be meaningfully documented as part of the HTTP server, then I'd
suggest it be moved to trunk too.
> This isn't an ajp or scgi or fastcgi server
> either, it's an http server, which means we should pull out those interfaces?
Those are all gateway interfaces *used* by an HTTP server to
communicate with a backend. If we had a better way to ship
modular code, like CPAN or gem, they wouldn't be part of our
core product. But we don't, so they are (or should be).
....Roy
Re: Technical reasons for -1 votes (?)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/1/2012 1:58 PM, Jim Jagielski wrote:
>
> On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote:
>
>> On 2/29/2012 6:25 PM, Roy T. Fielding wrote:
>>>
>>> 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.
>>
>> Which explains mod_macro how, exactly?
>
> At this point, my head exploded Scanners-like...
Funny, mine had exploded at the dis-congruity of;
>>> mod_ftp is there because it isn't an HTTP server.
which is apropos of what? This isn't an ajp or scgi or fastcgi server
either, it's an http server, which means we should pull out those interfaces?
Re: Technical reasons for -1 votes (?)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote:
> On 2/29/2012 6:25 PM, Roy T. Fielding wrote:
>>
>> 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.
>
> Which explains mod_macro how, exactly?
>
At this point, my head exploded Scanners-like...
Re: Technical reasons for -1 votes (?)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/29/2012 6:25 PM, Roy T. Fielding wrote:
>
> 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.
Which explains mod_macro how, exactly?
Re: Technical reasons for -1 votes (?)
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 29, 2012, at 9:42 AM, 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.
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.
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.
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.
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.
I see no reason not to commit mod_firehose, though I haven't had a
chance to look at the code myself. Nor am I willing to respect a
veto war based on the impact of past vetos.
Now, if you'll excuse me, I have at least two other walls to bang
my head on today ...
....Roy
Re: Technical reasons for -1 votes (?)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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>
Technical reasons for -1 votes (?)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.
Re: Proposal: adoption of mod_policy subproject
Posted by André Malo <nd...@perlig.de>.
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 (?).
nd
Re: Proposal: adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/14/2011 2:29 PM, William A. Rowe Jr. wrote:
> On 12/13/2011 12:39 PM, William A. Rowe Jr. wrote:
>> On 12/13/2011 10:22 AM, Graham Leggett wrote:
>>> - mod_policy: "HTTP protocol police"
>>>
>>> mod_policy is a set of httpd filters that detect and implement a set of HTTP protocol checks, the idea being you declare a policy for your development and testing environments, and requests/responses that violate the policy will either log a warning to the error_log or explicitly fail with a suitable error message, clearly telling the developer what they have done wrong, with the expectation that the developer fixes this before the code sees production.
>>
>> Very interesting, sounds generally useful to developers, and rounds out that
>> large gap in modules/test/ that we essentially offer very little for 'testing'
>> in terms of functional test modules.
>
> To clarify, I'm +1 for directly incorporating this into httpd/trunk/modules/test/
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.
This leaves +1; jim, minfrin. -1; wrowe. The vote fails for the time being.
Re: Proposal: adoption of mod_policy subproject
Posted by Graham Leggett <mi...@sharp.fm>.
On 14 Dec 2011, at 10:29 PM, William A. Rowe Jr. wrote:
>> Very interesting, sounds generally useful to developers, and rounds out that
>> large gap in modules/test/ that we essentially offer very little for 'testing'
>> in terms of functional test modules.
>
> To clarify, I'm +1 for directly incorporating this into httpd/trunk/modules/test/
>
> I don't think we need an independent subproject for this particular module, it
> seems rather straightforward. Default to build-but-don't-load. Provide an example
> config under docs/conf/extra/httpd-policy.conf
This makes sense to me.
Regards,
Graham
--
Re: Proposal: adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/13/2011 12:39 PM, William A. Rowe Jr. wrote:
> On 12/13/2011 10:22 AM, Graham Leggett wrote:
>> - mod_policy: "HTTP protocol police"
>>
>> mod_policy is a set of httpd filters that detect and implement a set of HTTP protocol checks, the idea being you declare a policy for your development and testing environments, and requests/responses that violate the policy will either log a warning to the error_log or explicitly fail with a suitable error message, clearly telling the developer what they have done wrong, with the expectation that the developer fixes this before the code sees production.
>
> Very interesting, sounds generally useful to developers, and rounds out that
> large gap in modules/test/ that we essentially offer very little for 'testing'
> in terms of functional test modules.
To clarify, I'm +1 for directly incorporating this into httpd/trunk/modules/test/
I don't think we need an independent subproject for this particular module, it
seems rather straightforward. Default to build-but-don't-load. Provide an example
config under docs/conf/extra/httpd-policy.conf
Bill
Re: Proposal: adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/13/2011 10:22 AM, Graham Leggett wrote:
> - mod_policy: "HTTP protocol police"
>
> mod_policy is a set of httpd filters that detect and implement a set of HTTP protocol checks, the idea being you declare a policy for your development and testing environments, and requests/responses that violate the policy will either log a warning to the error_log or explicitly fail with a suitable error message, clearly telling the developer what they have done wrong, with the expectation that the developer fixes this before the code sees production.
Very interesting, sounds generally useful to developers, and rounds out that
large gap in modules/test/ that we essentially offer very little for 'testing'
in terms of functional test modules.
> The set of policies to apply is as follows, but is expected to change with time:
>
> o Content-Type: check that it's present and valid
> o Content-Length: check that it is present and valid (used to ensure that keepalive requests between httpd and load balancers aren't prematurely terminated by a Connection: close)
Presume this means C-L and/or T-E chunked?
Re: Proposal: adoption of mod_policy subproject
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1!
On Dec 13, 2011, at 11:22 AM, Graham Leggett wrote:
> Hi all,
>
> As with mod_firehose, I have concluded negotiation with the BBC to open source some httpd modules that I wrote under the AL, and the BBC have very kindly agreed to donate the code to the ASF[1], which I believe would fit well as a subproject of httpd, and would like to know whether httpd would accept these.
>
> To be clear, 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.
>
> - mod_policy: "HTTP protocol police"
>
Re: Proposal: adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/21/2011 4:35 AM, Graham Leggett wrote:
> On 13 Dec 2011, at 6:22 PM, Graham Leggett wrote:
>
>> - mod_policy: "HTTP protocol police"
>
> Based on the support expressed, and the expressed preference that the module be part of httpd, I have written appropriate documentation for the module, as well as documentation targeted at developers affected by the module, and will commit them to trunk shortly.
>
> Further work can continue in svn.
Thanks Graham!
Re: Proposal: adoption of mod_policy subproject
Posted by Graham Leggett <mi...@sharp.fm>.
On 13 Dec 2011, at 6:22 PM, Graham Leggett wrote:
> - mod_policy: "HTTP protocol police"
Based on the support expressed, and the expressed preference that the module be part of httpd, I have written appropriate documentation for the module, as well as documentation targeted at developers affected by the module, and will commit them to trunk shortly.
Further work can continue in svn.
Regards,
Graham
--
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by Rich Bowen <rb...@rcbowen.com>.
On Mar 2, 2012, at 2:27 PM, William A. Rowe Jr. wrote:
> On 3/2/2012 12:28 PM, William A. Rowe Jr. wrote:
>> A proposal to adopt mod_policy is attached.
>>
>> [X] Option 1: adopt as trunk module
>
> Provided that mod_policy is droped into modules/testing
> .../debugging or .../experimental
Ditto. Option 1, in experimental.
--
Rich Bowen
rbowen@rcbowen.com :: @rbowen
rbowen@apache.org
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/2/2012 12:28 PM, William A. Rowe Jr. wrote:
> A proposal to adopt mod_policy is attached.
>
> [X] Option 1: adopt as trunk module
Provided that mod_policy is droped into modules/testing
.../debugging or .../experimental
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by Daniel Ruggeri <DR...@primary.net>.
On 3/2/2012 12:28 PM, William A. Rowe Jr. wrote:
> A proposal to adopt mod_policy is attached.
>
> [ ] Option 1: adopt as trunk module
> [ ] Option 2: adopt only as subproject
> [ ] Option 3: do not adopt
+1 to adopt as experimental module in trunk. This module has several uses beyond its original intent.
--
Daniel Ruggeri
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Mar 2, 2012 at 14:42, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Friday 02 March 2012, William A. Rowe Jr. wrote:
>> A proposal to adopt mod_policy is attached.
>>
>> [ ] Option 1: adopt as trunk module
>
> +1 to option 1
+1 to option 1.
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Friday 02 March 2012, William A. Rowe Jr. wrote:
> A proposal to adopt mod_policy is attached.
>
> [ ] Option 1: adopt as trunk module
+1 to option 1
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 2, 2012, at 1:28 PM, William A. Rowe Jr. wrote:
> A proposal to adopt mod_policy is attached.
>
> [X] Option 1: adopt as trunk module
> [ ] Option 2: adopt only as subproject
> [ ] Option 3: do not adopt
>
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/2/2012 12:28 PM, William A. Rowe Jr. wrote:
> A proposal to adopt mod_policy is attached.
>
> [ ] Option 1: adopt as trunk module
> [ ] Option 2: adopt only as subproject
> [ ] Option 3: do not adopt
72 hours have passed, consensus indicates that this module is accepted into
the httpd trunk modules/experimental/ tree. Thanks to all who voted.
Of mod_firehose and mod_policy, Legal VP Sam Ruby has asked for clarification
on this ticket https://issues.apache.org/bugzilla/show_bug.cgi?id=52322#c9
that all legal requirements are met. Any requirements from Sam must be met
before mod_policy can be committed (and for mod_firehose commits to remain
in subversion).
Graham, please respond to Sam's concerns, thanks.
Re: [RE-VOTE #2] adoption of mod_policy subproject
Posted by Rainer Jung <ra...@kippdata.de>.
On 02.03.2012 19:28, William A. Rowe Jr. wrote:
> A proposal to adopt mod_policy is attached.
>
> [X] Option 1: adopt as trunk module
> [ ] Option 2: adopt only as subproject
> [ ] Option 3: do not adopt
+1 for Option 1.
Regards,
Rainer
[RE-VOTE #2] adoption of mod_policy subproject
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
A proposal to adopt mod_policy is attached.
[ ] Option 1: adopt as trunk module
[ ] Option 2: adopt only as subproject
[ ] Option 3: do not adopt
[Prior to this vote, option 2 had previously passed with minfrin, jim
and wrowe in support. Subsequently minfrin, jim introduced option 1.
Please vote.]
On 12/13/2011 10:22 AM, Graham Leggett wrote:
> Hi all,
>
> As with mod_firehose, I have concluded negotiation with the BBC to open source some httpd modules that I wrote under the AL, and the BBC have very kindly agreed to donate the code to the ASF[1], which I believe would fit well as a subproject of httpd, and would like to know whether httpd would accept these.
>
> To be clear, 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.
>
> - mod_policy: "HTTP protocol police"
>
> One of the curses of developing restful services is that clients are "liberal in what they accept". This leads many developers of restful services to be "liberal in what they send", resulting in a service that works for the developer, but fails under load or other real world conditions.
>
> mod_policy is a set of httpd filters that detect and implement a set of HTTP protocol checks, the idea being you declare a policy for your development and testing environments, and requests/responses that violate the policy will either log a warning to the error_log or explicitly fail with a suitable error message, clearly telling the developer what they have done wrong, with the expectation that the developer fixes this before the code sees production.
>
> The set of policies to apply is as follows, but is expected to change with time:
>
> o Content-Type: check that it's present and valid
> o Content-Length: check that it is present and valid (used to ensure that keepalive requests between httpd and load balancers aren't prematurely terminated by a Connection: close)
> o Keepalive: more detailed keepalive checks
> o Vary: headers like User-Agent represent a potential caching DoS, if specified header is present in Vary, fail
> o Validation: if ETag/Last-Modified not present, fail
> o Conditional: if a conditional request doesn't comes back with a properly compliant conditional response, fail
> o No-cache: if the response is declared no cache, fail
> o Max-age: if the response has a max-age less than a given threshold, fail
> o Version: if the request was less than a given version (< HTTP1/1, for example) fail
>
> These are an initial set of policies that were created to meet current needs at the time of development, however it is expected this list will grow with time. mod_policy would benefit greatly from the experience of the authorities on HTTP that exist here, with the above policies being tightened up and improved.
>
> With the proliferation of restful services out there in various states of dubious protocol compliance, this set of filters can be a huge help to stop developers doing non compliant things, while not getting in the way of production code. The filters also help enforce that content remains cacheable, which for sites that endure high loads or thundering herds is important.
>
> The code is currently packaged as an RPM, wrapped in autotools, and a snapshot is available here:
>
> http://people.apache.org/~minfrin/bbc-donated/mod_policy/
>
> The corresponding README documenting in more detail is here:
>
> http://people.apache.org/~minfrin/bbc-donated/mod_policy/README
>
> The code itself is here:
>
> http://people.apache.org/~minfrin/bbc-donated/mod_policy/mod_policy.c
>
> Obviously the expectation is for the documentation to be completed and fleshed out.
>
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322
>
> Regards,
> Graham
> --
>
>