With regard to the faulty patch this revolves around: https://svn.apache.org/viewvc?view=revision&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 <j...@sunstarsys.com> 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 <j...@sunstarsys.com> wrote: > >> >> >> Get Outlook for iOS <https://aka.ms/o0ukef> >> ------------------------------ >> *From:* Ruediger Pluem <rpl...@apache.org> >> *Sent:* Monday, October 31, 2022 12:21 PM >> *To:* dev@httpd.apache.org <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. > <j...@sunstarsys.com> > 954.253.3732 <//954.253.3732> > > > -- Joe Schaefer, Ph.D. We only build what you need built. <j...@sunstarsys.com> 954.253.3732 <//954.253.3732>
