You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@gbiv.com> on 2012/03/01 01:25:09 UTC
Re: Technical reasons for -1 votes (?)
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 "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?