F/OSS is not about telling others how to write their code, Joe. You know this. And it *definitely* is not about demanding they spend *their* time to fix your pet issues.
If you have a problem with the code, then supply a fix. Your dozen emails are not fixing anything, and are certainly not endearing anybody to help you. Be nice, if you want help. -g On Sat, Oct 29, 2022 at 11:11 AM Joe Schaefer <j...@sunstarsys.com> wrote: > ...fell apart when Max asked you to release his patch to my screwup with > the NPE, and instead of cutting a release > with just that patch applied, you began the tragic process of dorking > around with apreq_header_attribute() as well. > > Just pull all those hacks out of apreq/trunk, and release exactly what Max > told you to release, and you will be good for another quiet decade of happy > libapreq2 users. > > If you do not take this advice, at least for your own personal > reputations, stop hacking the logic and start writing regression tests. > An internet-grade mfd parser is only as good as its weakest link, and I > just spent the past day telling you where that is. > > On Sat, Oct 29, 2022 at 12:06 PM Joe Schaefer <j...@sunstarsys.com> wrote: > >> All we need to do at this point is remember the basics of how to cut a >> security bugfix release. Everything in libapreq >> >> On Fri, Oct 28, 2022 at 3:04 PM <j...@sunstarsys.com> wrote: >> >>> Long time fan, not a first time caller. >>> >>> >>> >>> Libapreq2 was intended to be a safe,fast, standards compliant library- >>> primarily **safe** before all other priorities. Some of the work going >>> on lately in util.c is starting to undermine that prime directive, so I’d >>> like to better understand why these changes are happening, and why they are >>> snowballing into a less functional, less secure software product that is >>> driving up my support costs on CPAN. >>> >>> >>> >>> For instance, this revision 1867789 is a pure pessimization: it trades >>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal. >>> Just churn. >>> >>> >>> >>> Everything in the crufty, old apreq_header_attribute code I wrote was >>> completely tossed and reimplemented. Why? We’re just racking up CVE’s, >>> people are disabling the mfd parser altogether, and it no longer support >>> common use cases that people now complain about because it supported cases >>> in the wild that the new work does not. >>> >>> >>> >>> With the latest code coming out of p5p for Perl, there’s a whole new >>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination >>> is rock solid and screaming fast with HTTP/2. The only reason I resubbed >>> here is in the hopes of some synergy retaking these perl-related projects, >>> since mod_perl2 is the only game in town for embedded interpreters in >>> httpd2 (and no, lua is not the answer, it’s not thread safe either). >>> >>> >>> >>> >>> >>> Joe Schaefer, Ph.D. >>> >>> <j...@sunstarsys.com> >>> >>> 954.253.3732 <//954.253.3732/> >>> >>> SunStar Systems CMS <https://sunstarsys.com/CMS/> *- The Original >>> Markdown JAM Stack**™* >>> >>> >>> >> >> >> -- >> 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> > > >
