https://bz.apache.org/bugzilla/show_bug.cgi?id=70044
--- Comment #9 from Philippe Cloutier <[email protected]> --- (In reply to Rich Bowen from comment #7) > r1934245 (trunk) adds a PATH_INFO glossary entry — defines the term with an > example, links to AcceptPathInfo and RFC 3875 §4.1.5, and converts the first > prose mention in 14 files to glossary links for discoverability. Thank you very much > The trailing path information that follows the actual filename in a URL. I find this definition unclear, as: 1. Most URLs have no trailing path information. 2. A URL may have several actual filenames, even in the Windows/usual sense. For example, /app/scale.php/emoji/happy.jpg. 3. "trailing" and "follows" are redundant. 4. "information" is vague. I would suggest: > A second part in some URL-paths. If the URL-path starts with a handler > program’s path, it may be followed by a resource pathname. I suggest qualifying the link to the RFC, as the section has some CGI context. Perhaps "Specification in CGI context:". (In reply to Rich Bowen from comment #8) > Sorry you feel this way, Philippe. To me, they were pretty clearly > overlapping. It would have been one thing for someone to argue that they overlap. mod_alias and mod_rewrite *overlap*. This does *not* make any a *duplicate* of the other. It is rare that I file a duplicate report if there is already an existing decently clear public ticket, and it would be exceptional if I filed a duplicate of one of my own reports. > But, we're all volunteers here, and having our work called "incoherent" > isn't exactly uplifting. We all have different approaches to communication and feedback. I personally seek excellence, and feedback when I fail to achieve it (which is frequent; I am far from perfect). When I start a mandate, I tell colleagues I want to be told about my mistakes, and will bring chocolate/donuts/etc. when someone reports a mistake I did rather than fix it quietly. This tradition has been a significant source of joules. Receiving criticism does not uplift the mood in the short term. We’d all like to think that we’re perfect―I mean, almost perfect. But criticism may uplift the *skills*. I once discovered a colleague had quietly fixed a regression I introduced because I made an incorrect architectural assumption. I was very glad he fixed it before it caused chaos in production, but I could not believe he hadn't told me. I would necessarily have made such mistakes more times had I not realized it then. Now, welcome criticism has to be warranted. I just researched what "incoherence" means, and although the results are fairly confusing, I found that "incoherent" and "inconsistent" have senses considerably different from what I imagined. I do not know precisely which usages you are referring to, but I know I did use it, and very much understand how my thought must have been misunderstood now. Wherever I wrote “incoherent”, please just read “contradictory” if that seems more reasonable. I sincerely apologize for that, and thank you for sharing that criticism.🍩🍩🍩🍫🍩🍩 I wish I had realized that earlier as I see I used that term in tens of similar cases, but I will do my best to learn from this. > I do not believe that I have marked any issues > resolved "erroneously", but merely that you have different standards and > preferences. The first time this issue was marked as resolved was an error. I was not only referring to your actions, but I saw more (too many). > The continual insistence that the work isn't adequate is demoralizing. Many things in life are irritating. Trying to port an httpd application which has incorrect .htaccess comments to IIS is annoying. Trying to port an application which has incorrect .htaccess comments on a directive which is not properly specified to IIS is quite annoying, in particular when related directives have misleading specifications. Going to the ITS and realizing that nobody else bothered to report any of that can be irritating. I often manage that irritation by sacrificing even more time and thinking I will at least be among the last ones to endure that many irritants. Being reminded that several of these issues actually persisted for >1 decade when one is marked as finally fixed is frustrating. Realizing that it was not actually fixed and having to invest more time to explain that is extra frustrating. When after all that you still commit thousands more € to resolve some of the remaining issues, taking great care to stay accurate, clear, respectful, patient and helpful, and see your work qualified by people apparently on the PMC as “nit-picking” (when issues you report are not simply marked as resolved), it gets very frustrating. After decades of contributions which remain uncredited¹, reading from the only person who seems to still care and thanked you (thankfully repeatedly🤓) that he finds what he earlier said he appreciated demoralizing is―well―pretty demoralizing. Which does not mean I do not appreciate that you express it. Documenting is not easy, in particular when it's not your expertise. Documenting a server where a configuration mistake will likely affect end-users rather than administrators is hard. Documenting a server where a 1-character configuration mistake may cause hundreds or thousands of € of damages is hard. Documenting a complex C server without a UI like httpd is real hard. Documenting a complicated module―written decades ago―of an evolving complex C server without a UI like mod_rewrite, without funding, when it’s not your expertise, must be really very hard. Much of that work was done decades ago, when Wikipedia was way more incomplete and unreliable (because―you know―building an online encyclopedia without an httpd is hard), having to track evolving standards created by different organizations. And when there were no systems to facilitate systematic "code review". We say that bugs are shallow with enough eyeballs and think documentation issues are necessarily shallow, but that is not necessarily the case; if a module is too complicated; readers will struggle to tell whether they are experiencing a documentation issue, a behavioral issue, a configuration issue, a mix of these… or just confusion. If httpd provided a request processing debugger, documentation approximations and mistakes would have a lower impact, but currently, unexpected behavior can cause many questions; Is my rule well-written? Was my reload sufficient? Is my rule in the right file? Is the request correct? Is my browser’s cache interfering? Did I misunderstand the documentation? Is DNS cache interfering? Is another rule interfering? Is my httpd version buggy? Is the documentation correct? Even as a distinguished “serial bugger” and serial triager, I am not fully immune to “grumpy maintainers” and careless reporters/users. But you do endure negativity and the disagreements which come with it more easily, and get better at dealing with toxicity. If you only visit ITSs once every decade, and then spend the next 2 months doing nothing but dealing with problems, it will certainly end up affecting your mood. In issue tracking, just like in many other areas, balance is healthier. I appreciate your capacity to set emotions aside when dealing with a technical problem. I appreciate that you often go beyond the specific problem(s) reported and solve related/similar issues. I was very glad to notice you had committed a fix before I had to file Yet Another Ticket. But I don’t have an efficient way to communicate these. While serious projects all have an ITS, few have a Satisfaction Tracking System (although some do much better than httpd). Negativity generally overshadows positivity, and CBPP is even further from an equilibrium. I'm not sure what else I can make from your comment. If you have suggestions on how I could have addressed issues better, I am always open to constructive criticism. I feel an important source of your annoyance is conveyed by the word "continual". I don't think this crusade is necessarily endless; if it keeps the pace it had in the last 3 weeks, it would be over well before its 30th anniversary. But yes, 15 years is already surely longer than any of us would hope. Part of that comes from my modus operandi: the reports I send are focused, and if I discover a minefield, I will only file a few tickets about some of the component’s issues. The main reason is to prevent wasting my time on an abandoned component, but it’s also sometimes too broken to fully describe the breakage before cleanup starts. If there is bandwidth to handle these and they are solved by someone else, I verify and reevaluate the situation at that time. If the situation remains mostly the same and other issues persist, I report them at that time. On projects badly lacking reinforcements like httpd, this does massively stretch the time needed for a full cleanup, in particular in organizations which cannot afford an independent or collaborative review. That being said, we are all volunteers and no one should contribute more than what they are able and motivated to. If you believe the documentation has already become adequate, you are free to let others with more resources/interest deal with the rest. You already accomplished way more than your fair share. ¹: Except in an ITS which has become semi-private and in VCS logs. Then again, being credited (half of the time) with just a name as common as “Philippe” does not feel fully personal. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
