Developers on trunk are generally much faster at creating new features than they can be documented by the docs@ team. This situation is exacerbated by the humble (or not so humble) attempts of dev@ folks to attempt to explain their own new features, immediately after misnaming the new directive/option/feature. This could be trivially remedied with an ap_drbacchus_clone() function. Although the ap_drbacchus_progeny() function was already implemented, the httpd project will be hard pressed to wait the two decades before this benefit is fully realized. It is expected that this feature would dramatically reduce the number of new bugzilla incidents added during the alpha/beta and early GA periods (and many duplicates thereafter), by raising questions of the developers of exactly what they intended for their feature to accomplish, how on earth they expected to accomplish/configure it, and correcting their spelling of said features prior to release. However, there appears to be a patent minefield lurking in the implementation of this function, and legal-internal@ should be consulted on the methodology applied to derive a non-infringing implementation.
ap_drbacchus_clone() should do fractional arguments. A non-integer number of cloned DrBacchi would allow for N-misnamed-new-directives to be documented concurrently while allowing the remainder (smaller) clones to commit the build fluff. Beard colour should be a trivial matter.
w.r.t. comment #1, I would be very concerned that fractional clones would lead to more incomplete review and commits.
Meh. Fractional (irrational, perhaps) DrBacchoda could be assigned tasks by whichever body part(s) were effectively cloned and their hair quotient. I suggest: * Leg (medium hairyness) - kicking fajita to sense * Spleen (few hairs) - Softly codling newcommers * Face (severe hair) - Dealing with you
(In reply to comment #0) > > However, there appears to be a patent minefield lurking in the implementation > of this function, and legal-internal@ should be consulted on the methodology > applied to derive a non-infringing implementation. No need. We have an ICLA on file. We're good to go.
+1 someone should fix this. And document the fix.
Moving docs bugs to docs@httpd.a.o ownership.
Thanks. I'm flattered, and I'm very proud of the work that we've done over the last decade or so. But I'll take this opportunity to point out that I'm just one of a team - a team that is very active and very prolific. And we couldn't do any of it without the support of the folks who write the code in the first place. As for documenting the fix, it's something like this: 1) Listen to the customers. Listen on IRC, on the mailinglists, on the numerous third-party Apache HTTP Server support sites. Answer their questions and enhance the documents so that they don't need to ask it again. 2) Use the product and verify that what the documents say are actually correct, make sense, and are grammatically correct. 3) Lower the bar to entry, so that folks who want to contribute fixes to the docs are not discouraged from doing so. Exact implementation details are left to everyone in the community. Marking resolved, not because it's a closed issue, but because it's an always-open issue with a known and documented solution that we have only to continue to apply every day.