On Wed, Apr 18, 2018 at 1:01 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 17.04.2018 um 19:18 schrieb William A Rowe Jr <wr...@rowe-clan.net>: >> >>> On Tue, Apr 17, 2018 at 11:17 AM, Graham Leggett <minf...@sharp.fm> wrote: >>>> On 17 Apr 2018, at 6:08 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: >>>> >>>> No enhancement since 2011-12-19 has been presented for the collective >>>> community's scrutiny. >>> >>> Again, I’m not following. >>> >>> The architecture of v2.4 has been very stable, the need for breaking >>> changes has been largely non existent, and the focus since 2011 has been to >>> get changes backported to v2.4 instead. >>> >>> To distill this down to raw numbers, there have been 1546 discrete >>> backports (my simple grep of CHANGES) since 2011 - which has provided an >>> enormous amount of enhancement for the collective community’s scrutiny. >> >> And the corresponding number of regressions and behavior changes. None >> of these have enjoyed an "RC" or "beta", whatever one calls it, to >> validate before adoption - other than our claim of "best httpd yet". >> It has been an entirely new kitchen sink on every subversion release. > > All my substantial functional additions had beta releases for months before > being voted into the 2.4.x branch. With binary beta packages available for > several platforms by several supporters.
Yes; this is an exception. But as you first encountered, the scope of changes requires extensive rewiring of the hook processing phases and the architecture of modules themselves. You are in one instance (h2) spanning two worlds, one of very stable API's, architecture and predictable release cadences (nghttp2), and "us". Which makes your life easier, and more enjoyable? Since we never see a beta of the collective work, we don't pick up the various build problems (mod_md.h missing from make install on unix? CMake ignorant of new files and paths?) Your underlying module sources, built from apxs or similar I'm not worried about. The various patches required to glue it together is what I worry about. In most versioning schemes, these fundamental changes to the API, behavior and existing modules would have been set off with another version minor, or when redefining the module struct and existing hook behavior, a version major update. There would have been at least one beta of the collective work, issues would have been uncovered, then we return to fixing up the smaller bugs that don't require refactoring. > William, this painting our world a dark and miserable place is coming back > every few months. It is a disservice to the people who contribute changes > here. If stating the plain facts of the state of our current release(s) continues to be dark and miserable, that mirrors some disservice to the people who are *trying* to consume our software. I understand why you would say that from a recent PMC business private post; I plan to share (and paint dark) that picture with the full dev community, with some real improvements. >>> You seem to be making a mountain out of a molehill, I just don’t see the >>> problem you’re trying to solve. >> >> You are welcome to attribute this concern any way you like, and be >> satisfied with whatever yardstick you wish to measure it by. If you >> interpret our users as desiring enhancement and not stability, then >> those are the interests you should advocate. I'll leave this thread >> alone for another week again to give them the opportunity to chime in. > > There are alternative ways to be creative and innovate than going through > this PMC into a semi annual release. Exactly... that's why I started this thread without any prescription. Let's hear them all, and agree to some. There are some overloaded deeply-held beliefs here about the scarcity of version majors which we first need to set aside, starting another thread on the raw data from that exercise. > Releasing a module (plus some small patches) on github opens ways for > collaboration with people who like Apache and new stuff. Distros like Debian > unstable and Fedora pick up stuff from there. PPAs for apt are made > available. Steffen offers Windows builts. Yes; this is true of both subversion releases and major version releases. Take a radically incompatible example; PCRE 8 seems to have some perpetual life while PCRE 10 has very slow adoption, because old stack optimizations no longer play in a world where stack corruption exploits are trivial, and he deliberately made such things hard to do. Still, the distributors ship PCRE 10 to be consumed alongside the older cruftier choice. > The release cycle is hours, to the benefit of all interested. Be it a > blocking bug fixed or a nice feature implemented. These are mostly people who > do it for fun. Some even run large server clusters, so a „hobbyist“ label > does not apply. Hours, yes, but we've had a willing RM, who has automated even more of this than Jim or I had, and has a very hard time finding any target to point to. E.g. "ok, that looks like the right resolution to the last of the regressions... let's..." ... "...oh there are all these other shiny objects in STATUS... rock-n-roll!!!" No release in this in-between state. No pause to major enhancements or refactoring long enough for our users and code to catch their breath. And really no suggestion of continuity between 2.4.prev and 2.4.next, in config syntax or behavior. That doesn't sound fun for any user, casual or corporate. > It‘s simply fun. It‘s how I think FOSS is supposed to work and has worked > best in the past. I plan to continue doing it. ++1. Corollary; don't cause it to be un-fun for others, our user participants included. Need some wild west playground of the next version, right alongside some fenced "working" release of the "baked" version. Our M.m.s versioning schema isn't facilitating this at all, which is why I ask for any and all ideas. > If that stuff makes it all back into the Apache svn is not that relevant to > me. Because it‘s the least rewarding and fun part. > > (I am just talking about my feelings here, YMMV. ack, thanks for sharing!
