Sub-modules viability (was: [Vote] Considering mod_bmx for adoption by HTTP Server Project)
On Wed, Nov 30, 2016 at 2:05 PM, Jim Jagielski wrote: > > Module sub-modules NEVER get the love and attention they need > and warrant > It would be interesting to see this applied to fcgid on a fast-track. I don't know that ftp warrants it this moment. I don't know why arm4 is still one of our repositories with never-a-release. I made the direct-to-trunk-backport-2.4 proposal based on the efforts of Stefan who has continued to maintain a buildable external third party module of mod_h2, while keeping it in-sync with httpd 2.4. Maybe it is the better model. Older httpd flavors don't get the patch attention and backport considerations they need. Independently, Stefan can maintain a viable third party plug-in module for older flavors of httpd, but it can move forward with httpd core. No waiting on any backport votes, it simply happens when Stefan has cycles to do it. Contrawise, mod_h2 plugable add-on could have become a modules sub-project and available from the ASF. Either way, there is some level of synchronization required. Since Stefan is doing that all, it's truly his choice of what is simplest. Likewise, I'm happy to ensure mod_bmx on github continues to be a viable plug-in to httpd-2.2 or 2.4, and carry back the AL commits to the trunk/2.4 branch efforts at httpd. Having maintained a few sub-modules with mixed success, I'd be happy to see us retire the model, it simply doesn't work any better than landing on the perpetual 2.4.x release side-track. It seems like the entire effort has slipped the rail, but more on that in a few weeks when 2.4.24 is put to bed. In the meantime, there seems to already be consensus to shift mod_fcgid as well to trunk/.
Re: [Vote] Considering mod_bmx for adoption by HTTP Server Project
> On Nov 30, 2016, at 2:59 PM, William A Rowe Jr wrote: > > > [X] Accept mod_bmx into the httpd trunk (for possible backport consideration) > Module sub-modules NEVER get the love and attention they need and warrant.
[Vote] Considering mod_bmx for adoption by HTTP Server Project
I'm pleased to conversations with the principal folks that Hyperic/VMW and Pivotal are interested in passing along the mod_bmx codebase to the httpd project, if we will have it. https://github.com/hyperic/mod_bmx Scoped by the Hyperic team to represent mod_status info in a flexible and extensible bean-registry of items, which are reported over http in a json-parsable format, and replaced the need for mod_snmp, it also extends status insight into specific vhost activity, although this measurement requires locking which may be too painful for some admins. Written initially by out own Aaron Bannert contracting to Hyperic, it has been maintained by Ryan Morgan and myself, along with other odd patches, including recent fixes by Maxime Beck and folks on jfclere's team. Since we are already spanning vendors, httpd seems like the perfect commons space to further build on this work. I have a champion to shepard code grant paperwork through VMW/Hyperic/Pivotal signatories, if we choose to accepting the donation. There seem to be two paths for us to accept this donation, so I'll put this out as a three choice answer; [ ] Accept mod_bmx into the httpd project as a module sub-project [ ] Accept mod_bmx into the httpd trunk (for possible backport consideration) [ ] Decline mod_bmx donation Votes? Please feel free to switch the Subject: line to launch into side-discussions about the source code, all inquiries are welcome.
