Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

The reason this took so long for the community to diagnose isn't because of
ill-intent, but because it constituted
a change of behavior in the parser logic that wasn't surfaced in the
Changes file.

There is never going to come a time when there is any need for urgent
action on apreq- if it was easy to zero-day
it, it would have happened by now.  Thus, take as much time as you need
between releases to communicate with
the community about the nature of the deltas you intend to ship with any GA
release.  You have my email address
if you need to spitball any patchsets you are toying with; it's a lot less
painful to get my input in advance than after the fact.


On Mon, Oct 31, 2022 at 1:56 PM Joe Schaefer  wrote:

> With regard to the faulty patch this revolves around:
> https://svn.apache.org/viewvc?view=revision=1895107
> I do not expect you to know the specs, know the code, nor know what this
> patch actually does, in order to reject it from a GA release.
>
> I expect you to say to yourselves: High Risk, Low Reward, unmotivated
> patches are not appropriate in maintenance releases.
>
>
> On Mon, Oct 31, 2022 at 12:58 PM Joe Schaefer  wrote:
>
>> This stuff was written for an RFC era of the mid 2000s, and a lot of the
>> uncertainties around industry direction have been clarified in the years
>> since then, particularly as they relate to cookie standards.
>>
>> The nastiest code in here is the cookie parser logic that was required
>> back then.  If anything should be radically refactored and simplified,
>> start there.
>>
>> On Mon, Oct 31, 2022 at 12:36 PM Joe Schaefer  wrote:
>>
>>>
>>>
>>> Get Outlook for iOS 
>>> --
>>> *From:* Ruediger Pluem 
>>> *Sent:* Monday, October 31, 2022 12:21 PM
>>> *To:* dev@httpd.apache.org 
>>> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c
>>> over the past few years
>>>
>>>
>>>
>>> On 10/30/22 4:28 PM, Joe Schaefer wrote:
>>> > And to be frank- framing my input as me slagging on Yann is
>>> grotesque.  You ship GA releases as a team, and so when you ship a dud
>>> > like 2.17 you should take your lumps as a team.
>>>
>>> I admit that the libapreq2 codebase doesn't get that much review
>>> attention as other parts of httpd and does not draw that much
>>> developer interest. Hence we were very grateful that Yann took some time
>>> to do the needful, fixed the security issue and took it
>>> to a release to get that issue fixed for the users. Thank you Yann for
>>> this. The fact that at least the existing tests still
>>> passed after the changes was at least for me a good indicator that the
>>> changes don't break stuff and are fine.
>>> I also understand if you feel upset if the codebase you wrote and regard
>>> as better was changed and if you feel that the code
>>> deserves more love and care.
>>> The way to fix this is to participate here in a constructive way to get
>>> it in the direction you want it to be.
>>> If you feel that this isn't the correct community for this codebase we
>>> can also talk about this as Eric indicated.
>>> I am with Joe Orton and Greg that you are around for long enough to know
>>> that the way you started this brought attention to your
>>> desires but was counterproductive in many ways (tone of the emails,
>>> number of emails, top postings, too broad statements) to get
>>> things were you want them to be.
>>>
>>>
>>>
>>>
>>> Thanks Rüdiger.  I’m not interested in any type of stewardship for this
>>> code; my interests have long since moved on.  But my approach to software
>>> projects is to finish them, not for them to be perpetual motion machines,
>>> so I’m going to be concerned about frequent release cadences and constant
>>> churn that entails.
>>>
>>> I honestly do not expect apreq to be all that burdensome to maintain for
>>> you guys, regardless of all of the hot button items being fleshed out by
>>> the fact that it’s sitting in your trunk. I think that only helps mature
>>> and refine the product, regardless of how you deliver it to users.
>>>
>>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

With regard to the faulty patch this revolves around:
https://svn.apache.org/viewvc?view=revision=1895107
I do not expect you to know the specs, know the code, nor know what this
patch actually does, in order to reject it from a GA release.

I expect you to say to yourselves: High Risk, Low Reward, unmotivated
patches are not appropriate in maintenance releases.


On Mon, Oct 31, 2022 at 12:58 PM Joe Schaefer  wrote:

> This stuff was written for an RFC era of the mid 2000s, and a lot of the
> uncertainties around industry direction have been clarified in the years
> since then, particularly as they relate to cookie standards.
>
> The nastiest code in here is the cookie parser logic that was required
> back then.  If anything should be radically refactored and simplified,
> start there.
>
> On Mon, Oct 31, 2022 at 12:36 PM Joe Schaefer  wrote:
>
>>
>>
>> Get Outlook for iOS 
>> --
>> *From:* Ruediger Pluem 
>> *Sent:* Monday, October 31, 2022 12:21 PM
>> *To:* dev@httpd.apache.org 
>> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c over
>> the past few years
>>
>>
>>
>> On 10/30/22 4:28 PM, Joe Schaefer wrote:
>> > And to be frank- framing my input as me slagging on Yann is grotesque.
>> You ship GA releases as a team, and so when you ship a dud
>> > like 2.17 you should take your lumps as a team.
>>
>> I admit that the libapreq2 codebase doesn't get that much review
>> attention as other parts of httpd and does not draw that much
>> developer interest. Hence we were very grateful that Yann took some time
>> to do the needful, fixed the security issue and took it
>> to a release to get that issue fixed for the users. Thank you Yann for
>> this. The fact that at least the existing tests still
>> passed after the changes was at least for me a good indicator that the
>> changes don't break stuff and are fine.
>> I also understand if you feel upset if the codebase you wrote and regard
>> as better was changed and if you feel that the code
>> deserves more love and care.
>> The way to fix this is to participate here in a constructive way to get
>> it in the direction you want it to be.
>> If you feel that this isn't the correct community for this codebase we
>> can also talk about this as Eric indicated.
>> I am with Joe Orton and Greg that you are around for long enough to know
>> that the way you started this brought attention to your
>> desires but was counterproductive in many ways (tone of the emails,
>> number of emails, top postings, too broad statements) to get
>> things were you want them to be.
>>
>>
>>
>>
>> Thanks Rüdiger.  I’m not interested in any type of stewardship for this
>> code; my interests have long since moved on.  But my approach to software
>> projects is to finish them, not for them to be perpetual motion machines,
>> so I’m going to be concerned about frequent release cadences and constant
>> churn that entails.
>>
>> I honestly do not expect apreq to be all that burdensome to maintain for
>> you guys, regardless of all of the hot button items being fleshed out by
>> the fact that it’s sitting in your trunk. I think that only helps mature
>> and refine the product, regardless of how you deliver it to users.
>>
>> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

-- 
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

This stuff was written for an RFC era of the mid 2000s, and a lot of the
uncertainties around industry direction have been clarified in the years
since then, particularly as they relate to cookie standards.

The nastiest code in here is the cookie parser logic that was required back
then.  If anything should be radically refactored and simplified, start
there.

On Mon, Oct 31, 2022 at 12:36 PM Joe Schaefer  wrote:

>
>
> Get Outlook for iOS 
> --
> *From:* Ruediger Pluem 
> *Sent:* Monday, October 31, 2022 12:21 PM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c over
> the past few years
>
>
>
> On 10/30/22 4:28 PM, Joe Schaefer wrote:
> > And to be frank- framing my input as me slagging on Yann is grotesque.
> You ship GA releases as a team, and so when you ship a dud
> > like 2.17 you should take your lumps as a team.
>
> I admit that the libapreq2 codebase doesn't get that much review attention
> as other parts of httpd and does not draw that much
> developer interest. Hence we were very grateful that Yann took some time
> to do the needful, fixed the security issue and took it
> to a release to get that issue fixed for the users. Thank you Yann for
> this. The fact that at least the existing tests still
> passed after the changes was at least for me a good indicator that the
> changes don't break stuff and are fine.
> I also understand if you feel upset if the codebase you wrote and regard
> as better was changed and if you feel that the code
> deserves more love and care.
> The way to fix this is to participate here in a constructive way to get it
> in the direction you want it to be.
> If you feel that this isn't the correct community for this codebase we can
> also talk about this as Eric indicated.
> I am with Joe Orton and Greg that you are around for long enough to know
> that the way you started this brought attention to your
> desires but was counterproductive in many ways (tone of the emails, number
> of emails, top postings, too broad statements) to get
> things were you want them to be.
>
>
>
>
> Thanks Rüdiger.  I’m not interested in any type of stewardship for this
> code; my interests have long since moved on.  But my approach to software
> projects is to finish them, not for them to be perpetual motion machines,
> so I’m going to be concerned about frequent release cadences and constant
> churn that entails.
>
> I honestly do not expect apreq to be all that burdensome to maintain for
> you guys, regardless of all of the hot button items being fleshed out by
> the fact that it’s sitting in your trunk. I think that only helps mature
> and refine the product, regardless of how you deliver it to users.
>
> --
Joe Schaefer, Ph.D.
We only build what you need built.

954.253.3732 

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Get Outlook for iOS

From: Ruediger Pluem 
Sent: Monday, October 31, 2022 12:21 PM
To: dev@httpd.apache.org 
Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past 
few years



On 10/30/22 4:28 PM, Joe Schaefer wrote:
> And to be frank- framing my input as me slagging on Yann is grotesque.  You 
> ship GA releases as a team, and so when you ship a dud
> like 2.17 you should take your lumps as a team.

I admit that the libapreq2 codebase doesn't get that much review attention as 
other parts of httpd and does not draw that much
developer interest. Hence we were very grateful that Yann took some time to do 
the needful, fixed the security issue and took it
to a release to get that issue fixed for the users. Thank you Yann for this. 
The fact that at least the existing tests still
passed after the changes was at least for me a good indicator that the changes 
don't break stuff and are fine.
I also understand if you feel upset if the codebase you wrote and regard as 
better was changed and if you feel that the code
deserves more love and care.
The way to fix this is to participate here in a constructive way to get it in 
the direction you want it to be.
If you feel that this isn't the correct community for this codebase we can also 
talk about this as Eric indicated.
I am with Joe Orton and Greg that you are around for long enough to know that 
the way you started this brought attention to your
desires but was counterproductive in many ways (tone of the emails, number of 
emails, top postings, too broad statements) to get
things were you want them to be.




Thanks Rüdiger.  I’m not interested in any type of stewardship for this code; 
my interests have long since moved on.  But my approach to software projects is 
to finish them, not for them to be perpetual motion machines, so I’m going to 
be concerned about frequent release cadences and constant churn that entails.

I honestly do not expect apreq to be all that burdensome to maintain for you 
guys, regardless of all of the hot button items being fleshed out by the fact 
that it’s sitting in your trunk. I think that only helps mature and refine the 
product, regardless of how you deliver it to users.

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Ruediger Pluem]

On 10/31/22 5:21 PM, Ruediger Pluem wrote:
> 
> 
> On 10/30/22 4:28 PM, Joe Schaefer wrote:
>> And to be frank- framing my input as me slagging on Yann is grotesque.  You 
>> ship GA releases as a team, and so when you ship a dud
>> like 2.17 you should take your lumps as a team.
> 
> I admit that the libapreq2 codebase doesn't get that much review attention as 
> other parts of httpd and does not draw that much
> developer interest. Hence we were very grateful that Yann took some time to 
> do the needful, fixed the security issue and took it
> to a release to get that issue fixed for the users. Thank you Yann for this. 
> The fact that at least the existing tests still
> passed after the changes was at least for me a good indicator that the 
> changes don't break stuff and are fine.
> I also understand if you feel upset if the codebase you wrote and regard as 
> better was changed and if you feel that the code
> deserves more love and care.
> The way to fix this is to participate here in a constructive way to get it in 
> the direction you want it to be.
> If you feel that this isn't the correct community for this codebase we can 
> also talk about this as Eric indicated.
> I am with Joe Orton and Greg that you are around for long enough to know that 
> the way you started this brought attention to your
> desires but was counterproductive in many ways (tone of the emails, number of 
> emails, top postings, too broad statements) to get
> things were you want them to be.

Having said this, lets move forward and get into the details which cases are 
broken and what parts of the code cause this and
should be different.

Regards

Rüdiger

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Ruediger Pluem]

On 10/30/22 4:28 PM, Joe Schaefer wrote:
> And to be frank- framing my input as me slagging on Yann is grotesque.  You 
> ship GA releases as a team, and so when you ship a dud
> like 2.17 you should take your lumps as a team.

I admit that the libapreq2 codebase doesn't get that much review attention as 
other parts of httpd and does not draw that much
developer interest. Hence we were very grateful that Yann took some time to do 
the needful, fixed the security issue and took it
to a release to get that issue fixed for the users. Thank you Yann for this. 
The fact that at least the existing tests still
passed after the changes was at least for me a good indicator that the changes 
don't break stuff and are fine.
I also understand if you feel upset if the codebase you wrote and regard as 
better was changed and if you feel that the code
deserves more love and care.
The way to fix this is to participate here in a constructive way to get it in 
the direction you want it to be.
If you feel that this isn't the correct community for this codebase we can also 
talk about this as Eric indicated.
I am with Joe Orton and Greg that you are around for long enough to know that 
the way you started this brought attention to your
desires but was counterproductive in many ways (tone of the emails, number of 
emails, top postings, too broad statements) to get
things were you want them to be.


Regards

Rüdiger

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Schaefer]

Apologies for the bombast, Joe.

Constructively, I’m just offering development advice as an SME, which you are 
free to act on or not as the team sees fit. But you’re right that this is a 
Releng issue, not a development one, that I’m trying to surface in terms of how 
patch management is happening between HTTPD’s trunk and apreq’s.

Get Outlook for iOS

From: Joe Orton 
Sent: Monday, October 31, 2022 11:07:02 AM
To: dev@httpd.apache.org 
Subject: Re: [libapreq2] nits to pick about the patches to util.c over the past 
few years

On Sun, Oct 30, 2022 at 12:09:02AM -0400, Joe Schaefer wrote:
> Forgive me for summarizing, but I didn’t come here expecting help, much
> less collaboration on a solution.  I came here expecting to be scolded for
> having the temerity to critique the quality of the patch sets you’ve been
> shipping of late In libapreq2.  None of my opinions have changed on that
> subject, and won’t for some time.
>
> The point is I’m part of your extended support channels for libapreq2,
> because it’s easy and fun to help people who use the code.  I’m not here to
> complain, I’m here expecting more empathy for people like me who give their
> time graciously without expecting anything in return other than some
> measure of respect for the effort involved.

Joe, please dial down both the rhetoric and rate of fire.

Constructive criticism is always welcome here, we are quite used to
doing patch reviews. You've come in with a torrent of not very
constructive messages, unsurprisingly that won't get a hugely
sympathetic response from others. We all participate here voluntarily.

Regards, Joe

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Joe Orton]

On Sun, Oct 30, 2022 at 12:09:02AM -0400, Joe Schaefer wrote:
> Forgive me for summarizing, but I didn’t come here expecting help, much
> less collaboration on a solution.  I came here expecting to be scolded for
> having the temerity to critique the quality of the patch sets you’ve been
> shipping of late In libapreq2.  None of my opinions have changed on that
> subject, and won’t for some time.
> 
> The point is I’m part of your extended support channels for libapreq2,
> because it’s easy and fun to help people who use the code.  I’m not here to
> complain, I’m here expecting more empathy for people like me who give their
> time graciously without expecting anything in return other than some
> measure of respect for the effort involved.

Joe, please dial down both the rhetoric and rate of fire.

Constructive criticism is always welcome here, we are quite used to 
doing patch reviews. You've come in with a torrent of not very 
constructive messages, unsurprisingly that won't get a hugely 
sympathetic response from others. We all participate here voluntarily.

Regards, Joe