Sometime before end of year, perhaps I can upgrade apreq's autotool deps to something Ubuntu 22 can handle, for the purpose of dockerizing a build environment for the self-contained test suite in library/t. Getting automated builds that run those tests, at least periodically, will make a substantial difference in the quality of the development effort for apreq, even in httpd's trunk.
On Fri, Nov 4, 2022 at 3:40 PM Joe Schaefer <j...@sunstarsys.com> wrote: > One of these tests actually reported a problem with the "whimsical" patch > under consideration, Yann. > But instead of confronting you about it, Joe O just removed that test from > the suite prior to release. > > This is the very last time I expect to say something critical about 2.17. > Let's make it the last time I say > something critical about the team effort into producing any rapreq elease > going forward. You guys know better, > and all I ask is that you keep your own standards intact for apreq > (without adding any formal process to ensure it). > In the end, we're all volunteers- but don't dismiss the work of your > predecessors so quickly in the future. > > > On Fri, Nov 4, 2022 at 2:01 PM <j...@sunstarsys.com> wrote: > >> There's literally over 1M tests in library/t/parsers.c; all of them are >> trivial to adjust to taste. >> Going forward, if you want to establish different types of parser >> behaviors, positively document those behaviors in the test suite, just like >> your predecessors did. >> Let's not make what happened with 2.17 a new status quo for your efforts. >> >> -----Original Message----- >> From: Yann Ylavic <ylavic....@gmail.com> >> Sent: Wednesday, November 2, 2022 9:47 AM >> To: dev@httpd.apache.org >> Cc: Joe Schaefer <j...@sunstarsys.com> >> Subject: Re: [libapreq2] nits to pick about the patches to util.c over >> the past few years >> >> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer <j...@sunstarsys.com> wrote: >> > >> > 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. >> >> Please review r1905018 (with a CHANGES entry this time), along with >> r1905019 and r1905020 eventually. >> I'd suggest subscribing to c...@httpd.apache.org (if not already) and >> filter/mark subjects with "/httpd/apreq" if you don't want to miss anything. >> >> > >> > 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. >> >> That's not how it usually works though: r1895107 is dated "Nov 17, 2021", >> the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25, which left >> you 8 months to review the changes in trunk (and chime in..). >> >> >> Regards; >> Yann. >> > > > -- > 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>
