Re: The Version Bump fallacy [Was Re: Post 2.4.25]
> On Jan 3, 2017, at 8:04 PM, Noel Butler wrote: > > On 03/01/2017 23:11, Jim Jagielski wrote: > >> Back in the "old days" we used to provide complimentary builds >> for some OSs... I'm not saying we go back and do that necessarily, >> but maybe also providing easily consumable other formats when we >> do a release, as a "service" to the community might make a lot >> of sense. >> > 2 years ago it was decided to stop the official -deps (despite they are > included in dev still)... now you want to bring it back? (you'd have to if > you're going to roll usable binary packages or your "community service" > re-built packages are going to be broken) Nope. Didn't say that. And the inclusion on dev still is known and even explicitly addressed.
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On Tue, Jan 3, 2017 at 7:04 PM, Noel Butler wrote: > > On 03/01/2017 23:11, Jim Jagielski wrote: > > Back in the "old days" we used to provide complimentary builds > for some OSs... I'm not saying we go back and do that necessarily, > but maybe also providing easily consumable other formats when we > do a release, as a "service" to the community might make a lot > of sense. > > > 2 years ago it was decided to stop the official -deps (despite they are > included in dev still)... now you want to bring it back? (you'd have to if > you're going to roll usable binary packages or your "community service" > re-built packages are going to be broken) I don't think he said that. For years httpd shipped the compiled current openssl, expat, pcre sources as a binary. There was no sources package of these, although we did provide the .diff to get the packages to build correctly. Because HTTP/2 requires OpenSSL 1.0.2, that will have to be part of most packages, including semi-modern Linux flavors. PCRE[2] is unavoidable, and while libxml2 can sub in for libexpat, the SVN project would rather we bound to libexpat for specific features they rely on. > Although I as many others here prefer to roll our own due to our configs, and > not having to deal with bloat, I can see this having a positive effect for > users of a couple of distros who when they release brand new releases, come > with antiquated junk thats outdated and stays outdated, to give those users a > choice of using a modern code set would be good, but requires long term > dedication. Agreed - it simply has to land somewhere like /opt/apache/httpd/ or whatnot, to disambiguate whatever the user builds for themself in /usr/local/ and what the OS might provision in /usr/
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On 03/01/2017 23:11, Jim Jagielski wrote: > Back in the "old days" we used to provide complimentary builds > for some OSs... I'm not saying we go back and do that necessarily, > but maybe also providing easily consumable other formats when we > do a release, as a "service" to the community might make a lot > of sense. 2 years ago it was decided to stop the official -deps (despite they are included in dev still)... now you want to bring it back? (you'd have to if you're going to roll usable binary packages or your "community service" re-built packages are going to be broken) Although I as many others here prefer to roll our own due to our configs, and not having to deal with bloat, I can see this having a positive effect for users of a couple of distros who when they release brand new releases, come with antiquated junk thats outdated and stays outdated, to give those users a choice of using a modern code set would be good, but requires long term dedication. -- Kind Regard, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument signature.asc Description: OpenPGP digital signature
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On Jan 3, 2017 07:11, "Jim Jagielski" wrote: Back in the "old days" we used to provide complimentary builds for some OSs... I'm not saying we go back and do that necessarily, but maybe also providing easily consumable other formats when we do a release, as a "service" to the community might make a lot of sense. It could be really helpful. Or we can follow svn's lead and hand it entirely off to the broader community, which proved really effective on Windows, given the number of distros to now choose between. I haven't seen similar for RHEL users, for example. That said, only one major Linux distro (April Ubuntu LTS) is at OpenSSL 1.0.2, which is a necessary part of http/2's special sauce.
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
Back in the "old days" we used to provide complimentary builds for some OSs... I'm not saying we go back and do that necessarily, but maybe also providing easily consumable other formats when we do a release, as a "service" to the community might make a lot of sense.
Re: Post 2.4.25
On 31 Dec 2016, at 00:09, Stefan Fritsch wrote: > * the longer 2.6/3.0 takes the more half-baked/half-finished stuff > accumulates > that needs to be fixed before a release. > > But I don't have any ideas how to resolve this. Did you see my "A new release process?" thread? :)
Re: Post 2.4.25
On Saturday, 24 December 2016 08:29:35 CET Rich Bowen wrote: > From my perspective, watching Nginx gain traction through superior > marketing, and channeling Dilbert's Pointy Haired Boss in assuming that > everything which I have never done must be simple, I, for one, would > like to see us release a 2.6, and more generally, to release a 2.x every > 2 years, or less, rather than every 4 years, or more. There is the problem that on the one hand, one should do some invasive changes in trunk to improve the architecture. On the other hand, this is problematic if the 2.6/3.0 release is not coming soon because * it makes it difficult to backport stuff to 2.4.x * there is the danger that the people who did the invasive changes are no longer around when 2.6/3.0 is actually release. We had this problem with the authn/authz stuff for 2.4, which took quite some time to get fixed. * the longer 2.6/3.0 takes the more half-baked/half-finished stuff accumulates that needs to be fixed before a release. But I don't have any ideas how to resolve this. Cheers, Stefan
RE: The Version Bump fallacy [Was Re: Post 2.4.25]
I agree with a lot of what Daniel says, and I'm in a similar role with maintaining my organization's httpd RPM packages. However, I don't look at this suggestion so much as a replacement, but rather an additional option end users can use if they aren't up to the challenge of using sources, but can't get by with ancient builds in RHEL, etc. I personally doubt this would affect that many of the bigger users (let alone those on this list), as we would just keep using sources to keep up with what the LTS distros leave off (a 5+ year cycle is just too slow for the modern web tier). As someone who does distro packaging, I think this is completely the wrong distribution model, but it's also the quick and dirty one. Just throwing this out there, but a better middle of the road option for similar user coverage may be a more aggressive backporting of bleeding edge apache-related packages from development distros like Fedora to repositories maintained for the LTS distros. A lot of people already do this work independently, so perhaps much of the labor overhead could be knocked off with a bit more initial organizational effort, and referral/hosting support from the httpd project? Rick Houser Web Administration > -Original Message- > From: Daniel Ruggeri [mailto:drugg...@primary.net] > Sent: Friday, December 30, 2016 10:12 > To: dev@httpd.apache.org > Subject: Re: The Version Bump fallacy [Was Re: Post 2.4.25] > > On 12/28/2016 6:40 PM, Yehuda Katz wrote: > > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr > > mailto:wr...@rowe-clan.net>> wrote: > > > > Our adoption is *broadly* based on the OS distributions > > from vendors, not from people picking up our sources. > > Yes - some integrate directly from source, and others > > use a non-OS distribution. > > > > > > I think a significant number of users of nginx add the official nginx > > yum/apt sources and keep up to date that way > > (http://nginx.org/en/linux_packages.html#mainline). > > This is particularly true because the vendor-supplied version are so > > old. You can see this in the w3techs data: nginx 1.10.2 came out in > > October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8 > > usage has similar trends. > > > > A possible solution to this would be to start publishing binaries in a > > package-manager-accessible format. > > I am confident it would see a much higher rate of adoption. > > > > - Y > > I feel strongly about this... > > As a package builder/maintainer at $dayjob, this idea terrifies me. > Given the huge variation in distributions and what is current on those > platforms, the "best" option I see is to build for the least common > denominator (minimum common libc, APR, APR-UTIL, openssl, openldap, > etc). Otherwise, the package may only work on sufficiently modern > installations. Things like Docker containers for the different distros > are nice, but I'm not sure those are guaranteed to be current or > accurately represent what an installation will look like. Additionally, > vendors set different prefixes or split their configurations up > differently meaning we would then have to bite off the work of creating > vendor-specific packages (sucks for us) or force a standard installation > format (sucks for operators of the servers). A really good illustration > of this challenge is the layout differences between Debian and CentOS > where even the name of the server binary is changed from "httpd" to > "apache2" in the former distro. > > Or worse... we would have to bundle/vendor a copy of the dependencies > inside the httpd package. This becomes a nightmare for the package > builders because (as wrowe pointed out recently) it requires us to build > these updated libraries and push the new package at some cadence as well > as changing library search paths to potentially funky locations. It also > becomes a challenge for server operators because a library now exists in > two locations on the machine so compliance auditing gets forked (my > httpd installation may be using openssl 1.0.2j but my postfix server may > be using 0.9.8zh). > > Also, I'm sure it goes without saying, but we can't reasonably consider > either approach without full CI... doing all this manually is > unmaintainable (heh - ask me how I know). > > -- > Daniel Ruggeri
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On 12/28/2016 6:40 PM, Yehuda Katz wrote: > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr > mailto:wr...@rowe-clan.net>> wrote: > > Our adoption is *broadly* based on the OS distributions > from vendors, not from people picking up our sources. > Yes - some integrate directly from source, and others > use a non-OS distribution. > > > I think a significant number of users of nginx add the official nginx > yum/apt sources and keep up to date that way > (http://nginx.org/en/linux_packages.html#mainline). > This is particularly true because the vendor-supplied version are so > old. You can see this in the w3techs data: nginx 1.10.2 came out in > October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8 > usage has similar trends. > > A possible solution to this would be to start publishing binaries in a > package-manager-accessible format. > I am confident it would see a much higher rate of adoption. > > - Y I feel strongly about this... As a package builder/maintainer at $dayjob, this idea terrifies me. Given the huge variation in distributions and what is current on those platforms, the "best" option I see is to build for the least common denominator (minimum common libc, APR, APR-UTIL, openssl, openldap, etc). Otherwise, the package may only work on sufficiently modern installations. Things like Docker containers for the different distros are nice, but I'm not sure those are guaranteed to be current or accurately represent what an installation will look like. Additionally, vendors set different prefixes or split their configurations up differently meaning we would then have to bite off the work of creating vendor-specific packages (sucks for us) or force a standard installation format (sucks for operators of the servers). A really good illustration of this challenge is the layout differences between Debian and CentOS where even the name of the server binary is changed from "httpd" to "apache2" in the former distro. Or worse... we would have to bundle/vendor a copy of the dependencies inside the httpd package. This becomes a nightmare for the package builders because (as wrowe pointed out recently) it requires us to build these updated libraries and push the new package at some cadence as well as changing library search paths to potentially funky locations. It also becomes a challenge for server operators because a library now exists in two locations on the machine so compliance auditing gets forked (my httpd installation may be using openssl 1.0.2j but my postfix server may be using 0.9.8zh). Also, I'm sure it goes without saying, but we can't reasonably consider either approach without full CI... doing all this manually is unmaintainable (heh - ask me how I know). -- Daniel Ruggeri
Re: Post 2.4.25
On Thu, Dec 29, 2016 at 8:23 AM, Jim Jagielski wrote: > >> On Dec 28, 2016, at 6:28 PM, William A Rowe Jr wrote: >> >> Because fixing r->uri is such a priority, trust that I'll be voting every >> 2.6 candidate a -1 until it exists. I don't know why the original httpd >> founders are so hung up on version number conservation, they are cheap, but >> we are breaking a key field of a core request structure and no other OSS >> project would be stupid enough to call that n.m+1. > > Who is digging in their heels and blocking new development > now? > > So you are admitting that you will "veto" (although you > can't veto a release) any 2.5.* "releases" unless and > until r->uri is "fixed". Wow, Jim, how did you misread my assertion that I'd oppose 2.6 GA or 3.0 GA release until feature "X", where "X" represents the heavy-lift of not using filesystem syntax as the uri path except for files, honoring the URI and HTTP RFC, and therefore requiring some module authors to re-think how they consumed or changed/assigned r->uri. Modules such as proxy would actually pass on the *presented* uri (if valid) to the back end http server - just imagine that. That change I'm expecting we all want to call out as 3.0 for our developers, even though there are no directives changed for our users so administration doesn't change. How did you jump to the conclusion that I'd block an -alpha or -beta release on the 2.5.x trunk? Usually takes some number of incremental -alpha/-beta tags to get to GA. And how did you translate 'vote -1' to veto?
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On Thu, Dec 29, 2016 at 8:25 AM, Jim Jagielski wrote: > It wasn't the paste that was the problem, but the inability > of other email clients to determine from your email what > parts/sections are quoted from *previous* emails. Yann pointed me in the right direction, I believe it is fixed now. Thanks for the heads-up! >> On Dec 28, 2016, at 5:49 PM, William A Rowe Jr wrote: >> >> Hi Jim, >> >> Talk to Google and the OpenOffice Team, that was a paste from OpenOffice >> Calc. >> >> I'll be happy to start summarizing as a shared Google sheet. Google sheet might still be useful, so I'll maintain that as a general purpose collection of shared-with-httpd-dev tabs.
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
> On Dec 28, 2016, at 7:40 PM, Yehuda Katz wrote: > > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr > wrote: > Our adoption is *broadly* based on the OS distributions > from vendors, not from people picking up our sources. > Yes - some integrate directly from source, and others > use a non-OS distribution. > > I think a significant number of users of nginx add the official nginx yum/apt > sources and keep up to date that way > (http://nginx.org/en/linux_packages.html#mainline). > This is particularly true because the vendor-supplied version are so old. You > can see this in the w3techs data: nginx 1.10.2 came out in October and > already makes up 75% of all nginx 1.10 users. nginx 1.11.8 usage has similar > trends. > > A possible solution to this would be to start publishing binaries in a > package-manager-accessible format. > I am confident it would see a much higher rate of adoption. > Good point. +1
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
It wasn't the paste that was the problem, but the inability of other email clients to determine from your email what parts/sections are quoted from *previous* emails. > On Dec 28, 2016, at 5:49 PM, William A Rowe Jr wrote: > > Hi Jim, > > Talk to Google and the OpenOffice Team, that was a paste from OpenOffice Calc. > > I'll be happy to start summarizing as a shared Google sheet. > > Cheers, > > Bill > > > On Dec 28, 2016 14:22, "Jim Jagielski" wrote: > Bill, I don't know if it's just my Email client or not (doesn't > look like it) but could you fix your Email client? It's impossible to > reply and have the quoted parts parsed out correctly. I think > it's to do w/ your messages being RTF or something. > > Thx! > > Included is an example of how a Reply misses quote levels... > > > On Dec 28, 2016, at 1:34 PM, William A Rowe Jr wrote: > > > > On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski wrote: > > cPanel too... They are moving to EA4 which is Apache 2.4. > > > > If not moved yet, that example wouldn't be helpful, it reinforces my point > > four years later. But EA itself seems to track pretty closely to the most > > contemperanious versions, looks like within a month. > > > > > > So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't > > have the reach or range of larger ones (2.4.x->2.6/3.0) isn't > > quite accurate. > > > > It's entirely accurate. It isn't all-encompassing. We have that data too, > > let's tear down SecuritySpace's Nov '16 dataset; > > http://www.securityspace.com/s_survey/data/201611/servers.html > > >
Re: Post 2.4.25
> On Dec 28, 2016, at 6:28 PM, William A Rowe Jr wrote: > > > Because fixing r->uri is such a priority, trust that I'll be voting every 2.6 > candidate a -1 until it exists. I don't know why the original httpd founders > are so hung up on version number conservation, they are cheap, but we are > breaking a key field of a core request structure and no other OSS project > would be stupid enough to call that n.m+1. > Who is digging in their heels and blocking new development now? So you are admitting that you will "veto" (although you can't veto a release) any 2.5.* "releases" unless and until r->uri is "fixed". Which implies, obviously, a very substantial refactoring. Which implies time. Which implies that if you also say "no new enhancements in 2.4" that it will be a long time until anything new and useful will be added to, or available to, our end-users until some unknown future time. And that is acceptable to you? And no one I know of in any way is "hung up on version number conservation", and that is moot and strawman anyway. As fair warning, I fully expect that we will release 2.4.26 within the next 3 months. I also fully expect that some "new enhancements" from trunk to be backported and be in that release. I simply care about continuing to keep Apache httpd relevant and a continued viable offering for our community. That means us working on next-gen, of course, but also maintaining and fostering a community until next-gen exists.
Re: Post 2.4.25
Am 29.12.2016 um 07:08 schrieb William A Rowe Jr: (Again, it's gmail, /shrug. I can attempt to undecorate but doubt I'm moving to a local client/mail store again. If anyone has good gmail formatting tips for their default settings, I'd love a pointer.) yes, setup thunderbird and gmail with IMAP for mailing-lists so that your sent and received mail are as now on the server or setup roundcube to access gmail via IMAP/SMTP and configure it to prefer plaintext or complain loud enough to google that they are fools when they convert a plaintext message to html while press reply
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
> Am 29.12.2016 um 01:40 schrieb Yehuda Katz : > > On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr > wrote: > Our adoption is *broadly* based on the OS distributions > from vendors, not from people picking up our sources. > Yes - some integrate directly from source, and others > use a non-OS distribution. > > I think a significant number of users of nginx add the official nginx yum/apt > sources and keep up to date that way > (http://nginx.org/en/linux_packages.html#mainline). > This is particularly true because the vendor-supplied version are so old. You > can see this in the w3techs data: nginx 1.10.2 came out in October and > already makes up 75% of all nginx 1.10 users. nginx 1.11.8 usage has similar > trends. > > A possible solution to this would be to start publishing binaries in a > package-manager-accessible format. > I am confident it would see a much higher rate of adoption. Very good point. Myself using a ppa for my ubuntu server via deb http://ppa.launchpad.net/ondrej/apache2/ubuntu trusty main that updates very quickly. It already has 2.4.25. There are other people doing this for various distros. The least we could do is document the ones we know, talk to people how they see it continue. Offer a https place and visibility on Apache servers maybe? Does that make sense? > - Y Stefan Eissing bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
On the subject of r->uri [was: Post 2.4.25]
On Wed, Dec 28, 2016 at 6:42 PM, Yann Ylavic wrote: > [Bill, you definitely should do something with your email client, e.g. > using plain text only, replying to your messages breaks indentation > level (like the number of '>' preceding/according to the initial > message)]. > (Again, it's gmail, /shrug. I can attempt to undecorate but doubt I'm moving to a local client/mail store again. If anyone has good gmail formatting tips for their default settings, I'd love a pointer.) > On Thu, Dec 29, 2016 at 12:28 AM, William A Rowe Jr > wrote: > > > > On Dec 24, 2016 07:57, "Jim Jagielski" wrote: > > > > Well as breaking changes go, changing URI to remain an encoded value and > to > > mandate module authors accept that req_rec is free threaded are breaking > > changes. > > Not sure what the second point means, but preserving r->uri while also > allowing to (and internally work with) an escaped form of the URI does > not necessarily require an API change. > (We could possibly have an opaque struct to manipulate the URI in its > different forms and some helper(s) be compatible with the API changes' > requirements, e.g. 2.4.x). > To be clear, this isn't possible. There are multiple meanings of every path segment character which is in the reserved set. There is no way to preserve these multiple meanings in a decoded context. The parallel entities may exist in any undecoded string. So r->uri, if it still exists, will be subsumed by some variable like r->uri_path_unencoded and be retrievable into a decoded form. Functions such as ap_hook_map_to_storage, in the filesystem backend, will only be interested in the decoded form. Functions such as the http proxy module will only be interested in passing a never-mangled version of the encoded uri. Even if r->uri is available as a read-only input, there is no simple way for httpd to resolve r->uri manipulations if changed in place (it isn't const) and whether an r->uri_path_unencoded mismatch which is canonical, and what mishmash the legacy abuser of r->uri did with these parallel reserved characters in their encoded and unnencoded forms. We are stuck with the current mess of various %-escape workarounds until we replace the core assumption. This deserves a long discussion which already exists in the security@ list, but needs to be pushed outward on dev@, preferably by the original authors of these thoughts. That includes the r->uri preserving flavor that you mention above, as well as the various discussions about the % entity encoding, and my concerns about canonicalization. With some first-level triage already complete, there is no reason for uri discussion to remain 'behind the curtain.'
Re: Post 2.4.25
[Bill, you definitely should do something with your email client, e.g. using plain text only, replying to your messages breaks indentation level (like the number of '>' preceding/according to the initial message)]. On Thu, Dec 29, 2016 at 12:28 AM, William A Rowe Jr wrote: > > On Dec 24, 2016 07:57, "Jim Jagielski" wrote: > [For example, here I had to add a '>' for Jim's original text to be associated with the above "Jim ... wrote:"] >> >> My point is that even having a 6 month minimal (and that >> is, IMO, widely optimistic and unrealistic) of "no new >> features for 2.4" means that we are basically giving people >> reasons to drop httpd. It would be a widely different story >> if (1) trunk was ready to release and (2) we "committed" to >> releasing trunk quickly by focusing on low-hanging fruit >> which would make lives happier and better for our end-users. >> As I said, my fear is that we will not be able to "control" >> ourselves in limiting what is in 2.6, which will push the >> actual release far past the point where it is even relevant. > > Well as breaking changes go, changing URI to remain an encoded value and to > mandate module authors accept that req_rec is free threaded are breaking > changes. Not sure what the second point means, but preserving r->uri while also allowing to (and internally work with) an escaped form of the URI does not necessarily require an API change. (We could possibly have an opaque struct to manipulate the URI in its different forms and some helper(s) be compatible with the API changes' requirements, e.g. 2.4.x). Regarding the changes in configuration/behaviours, I don't think we should break things anyway (even accross majors, if possible/relevant of course), but rather provide options to have the one or the other behaviour (trunk having the now considered better behaviour, stable(s) the compatible one). My point is mainly that rather than focusing on version numbers, we probably should focus on: 1. what we have now (in trunk), and want to backport 2. what we don't have now, do it (the better wrt trunk), and go to 1. There's (almost) always a way to backport things, though it should not prevent us from doing the *necessary* changes (in trunk) for new improvements/features. Yet, first step is the "inventory" of what we have/want, each/all of us involved and constructive... Once this is done, let's see what is compatible or not (and if yes at which cost). If we are going to introduce incompatible features, let's do 3.x. If we are going to introduce many features at once, let's do 2.6.x (that's an announce/marketing "value", the user does not care about the version, (s)he does about the features). Otherwise let's continue improving trunk with 2.4.x. When we start implementing new features, first discuss/specify them, then implement, and see if it's compatible/backportable. For now, I don't see many (if any) incompatibilities in trunk (I surely don't have an exhaustive view), but many improvements to backport. Just my 2 cts... Regards, Yann.
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On Wed, Dec 28, 2016 at 12:35 AM, William A Rowe Jr wrote: > Our adoption is *broadly* based on the OS distributions > from vendors, not from people picking up our sources. > Yes - some integrate directly from source, and others > use a non-OS distribution. > I think a significant number of users of nginx add the official nginx yum/apt sources and keep up to date that way ( http://nginx.org/en/linux_packages.html#mainline). This is particularly true because the vendor-supplied version are so old. You can see this in the w3techs data: nginx 1.10.2 came out in October and already makes up 75% of all nginx 1.10 users. nginx 1.11.8 usage has similar trends. A possible solution to this would be to start publishing binaries in a package-manager-accessible format. I am confident it would see a much higher rate of adoption. - Y
Re: Post 2.4.25
On Dec 24, 2016 08:32, "Eric Covener" wrote: > I'm not saying we don't do one so we can do the other; I'm > saying we do both, at the same time, in parallel. I still > don't understand why that concept is such an anathema to some > people. I also worry about our ability to deliver a 3.0 with enough re-architecture for us and and function for users, vs a more continuous delivery (apologies for bringing buzzaords to dev@httpd) cadence on 2.4 as we've been in. Here is the confusion (see the versioning thread.) 2.6 is a break in ABI compatibility. 3.0 is a break in API compatibility. Size in this case doesn't matter. Any break at all merits these changes. We are not a commercial product. We are httpd. Nobody cares what the version no is other than us, they very largely install and forget, OS vendors grab new at one point in their distribution gathering phase and don't revisit. Adoption outside of OS distros is largely irrelevant. Talk about do-nothing, PCRE2 has been out a very long time with all the activity and no adoption, PCRE 8.x is on life support with little pulse and is the defacto standard. Your assumptions don't reflect the actual adoption behaviors.
Re: Post 2.4.25
On Dec 24, 2016 07:57, "Jim Jagielski" wrote: > On Dec 24, 2016, at 8:29 AM, Rich Bowen wrote: > > On 12/23/2016 03:52 PM, Jim Jagielski wrote: >> Personally, I don't think that backporting stuff to >> 2.4 prevents or disallows development on 2.6/3.0. In >> fact, I think it helps. We can easily do both... >> after all, we are still "working" on 2.2. >> >> As I have also stated, my personal belief is that >> 2.4 is finally reaching some traction, and if we >> "turn off" development/enhancement of 2.4, we will >> stop the uptake of 2.4 in its track. We need to keep >> 2.4 viable and worthwhile we, at the same time, work >> on 2.6/3.0. I think we all understand that getting >> 2.6/3.0 out will not be a quick and/or painless >> action. > > From my perspective, watching Nginx gain traction through superior > marketing, and channeling Dilbert's Pointy Haired Boss in assuming that > everything which I have never done must be simple, I, for one, would > like to see us release a 2.6, and more generally, to release a 2.x every > 2 years, or less, rather than every 4 years, or more. > > My opinion on this, I would emphasize, is 100% marketing, and 0% > technical. I realize we "don't do" marketing, but if we want to still ve > having the fun of doing this in another 20 years, it may be necessary to > get our name out there a little more frequently in terms of doing new > things. We are frankly not great at telling the world about the cool new > things we're doing. > Yeah, right now the way we are "doing marketing" is by continually adding features and enhancements to 2.4... It is what keeps 2.4 relevant and is what either keeps current httpd users using httpd or maybe help those on the fence decide on httpd instead of nginx/whatever. And again to play devil's advocate, how has that worked out in the four years of httpd 2.4? My point is that even having a 6 month minimal (and that is, IMO, widely optimistic and unrealistic) of "no new features for 2.4" means that we are basically giving people reasons to drop httpd. It would be a widely different story if (1) trunk was ready to release and (2) we "committed" to releasing trunk quickly by focusing on low-hanging fruit which would make lives happier and better for our end-users. As I said, my fear is that we will not be able to "control" ourselves in limiting what is in 2.6, which will push the actual release far past the point where it is even relevant. Well as breaking changes go, changing URI to remain an encoded value and to mandate module authors accept that req_rec is free threaded are breaking changes. We did that on conn_rec post-2.2. But I suspect that we have now done this to req_rec with the event mpm and sf's http2 enhancements already on 2.4? To be clear, if our goal was "Fork trunk as 2.5 NOW, polish and tune 2.5 'as-is' with minimal major refactoring with the goal of getting 2.6 out ASAP" then yeah, sure, the idea of "no new features in 2.4" would have some merit. But based on current conversation, it's obvious that, at least to me, that won't happen and we will be continually refactoring 2.6 to make it a 3.0. Two mistakes. If we commit to a new contract on these two things, there is never 2.6. Because fixing r->uri is such a priority, trust that I'll be voting every 2.6 candidate a -1 until it exists. I don't know why the original httpd founders are so hung up on version number conservation, they are cheap, but we are breaking a key field of a core request structure and no other OSS project would be stupid enough to call that n.m+1. So you can presume there is no such thing as 2.6. Error 2 and you ignored the first reply, there is no branch until 3.0 occurs. I'll save that detail for the next post. Again, you don't "stop" development on a current release until the next release is ready or, at least, "this close" to being ready. You don't sacrifice the present, nor do you leave your users in that limbo. Users had been in limbo 10 months for security fixes and far longer for bug fixes PatchAvailable in bugzilla, and you are worried about feature development on an maintenance branch. Sigh...
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On Dec 28, 2016 10:34, "William A Rowe Jr" wrote: Specific Revision Of all Most Recent Of m.m Of all Apache/1.3.x 391898 3.33% 1.3.42 42392 10.82% 0.36% Apache/2.0.x 551117 4.68% 2.0.64 36944 6.70% 0.31% Apache/2.2.x 7129391 60.49% 2.2.31 1332448 18.78% 11.31% Apache/2.4.x 3713364 31.51% 2.4.17+ 1502061 42.90% 12.74% 11785770 2.4.23 754385 21.54% 6.40% Since this table is illegible to some, please see the second tab of https://docs.google.com/spreadsheets/d/1aOxBRZ2IHsUJJcQNXu-oe6la4wMRIHN2mOlJCQGRy0k/edit?usp=drivesdk The first tab is a crossref of many OS distribution components used by httpd, as well as httpd itself.
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
Hi Jim, Talk to Google and the OpenOffice Team, that was a paste from OpenOffice Calc. I'll be happy to start summarizing as a shared Google sheet. Cheers, Bill On Dec 28, 2016 14:22, "Jim Jagielski" wrote: > Bill, I don't know if it's just my Email client or not (doesn't > look like it) but could you fix your Email client? It's impossible to > reply and have the quoted parts parsed out correctly. I think > it's to do w/ your messages being RTF or something. > > Thx! > > Included is an example of how a Reply misses quote levels... > > > On Dec 28, 2016, at 1:34 PM, William A Rowe Jr > wrote: > > > > On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski wrote: > > cPanel too... They are moving to EA4 which is Apache 2.4. > > > > If not moved yet, that example wouldn't be helpful, it reinforces my > point > > four years later. But EA itself seems to track pretty closely to the most > > contemperanious versions, looks like within a month. > > > > > > So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't > > have the reach or range of larger ones (2.4.x->2.6/3.0) isn't > > quite accurate. > > > > It's entirely accurate. It isn't all-encompassing. We have that data too, > > let's tear down SecuritySpace's Nov '16 dataset; > > http://www.securityspace.com/s_survey/data/201611/servers.html > > > >
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
Bill, I don't know if it's just my Email client or not (doesn't look like it) but could you fix your Email client? It's impossible to reply and have the quoted parts parsed out correctly. I think it's to do w/ your messages being RTF or something. Thx! Included is an example of how a Reply misses quote levels... > On Dec 28, 2016, at 1:34 PM, William A Rowe Jr wrote: > > On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski wrote: > cPanel too... They are moving to EA4 which is Apache 2.4. > > If not moved yet, that example wouldn't be helpful, it reinforces my point > four years later. But EA itself seems to track pretty closely to the most > contemperanious versions, looks like within a month. > > > So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't > have the reach or range of larger ones (2.4.x->2.6/3.0) isn't > quite accurate. > > It's entirely accurate. It isn't all-encompassing. We have that data too, > let's tear down SecuritySpace's Nov '16 dataset; > http://www.securityspace.com/s_survey/data/201611/servers.html >
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
William A Rowe Jr in gmane.comp.apache.devel (Wed, 28 Dec 2016 10:46:51 -0600): >On Wed, Dec 28, 2016 at 9:05 AM, Jan Ehrhardt wrote: > >> Do not underestimate the influence of control panels. On all my Centos >> servers I am running Directadmin. DA always offers to upgrade to the >> latest release within a day after the release. Hence, I am running >> Apache 2.4.25 everywhere at the moment. > > Excellent pointer. Thanks Jan. BTW: I would be more hesitant to directly install a new release if I would not have tested the dev/dist release candidates on my Windows dev-server. But I am quite sure a lot of Directadmin users follow suit soon. -- Jan
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On Wed, Dec 28, 2016 at 9:13 AM, Jim Jagielski wrote: > cPanel too... They are moving to EA4 which is Apache 2.4. > If not moved yet, that example wouldn't be helpful, it reinforces my point four years later. But EA itself seems to track pretty closely to the most contemperanious versions, looks like within a month. So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't > have the reach or range of larger ones (2.4.x->2.6/3.0) isn't > quite accurate. > It's entirely accurate. It isn't all-encompassing. We have that data too, let's tear down SecuritySpace's Nov '16 dataset; http://www.securityspace.com/s_survey/data/201611/servers.html First off, if you follow that link, you'll find much larger numbers associated to those specific revisions shipped with the likes of RHEL or CentOS, Ubuntu (particularly -LTS flavors), etc etc etc. That was my contention in the top post. But let's quantify 'accuracy' as you defined it in the reply... Specific Revision Of all Most Recent Of m.m Of all Apache/1.3.x 391898 3.33% 1.3.42 42392 10.82% 0.36% Apache/2.0.x 551117 4.68% 2.0.64 36944 6.70% 0.31% Apache/2.2.x 7129391 60.49% 2.2.31 1332448 18.78% 11.31% Apache/2.4.x 3713364 31.51% 2.4.17+ 1502061 42.90% 12.74% 11785770 2.4.23 754385 21.54% 6.40% The applicable data are 37.47% of all 'Apache[/n[.n[.n]]]' items, meaning that some 2/3rds of users drop the ServerTokens down to product only or major version only, and we can't derive anything useful from them, so we will ignore the Apache and Apache/2 references for our % evaluations, 'Of all' refers to those with at least Apache/2.x designations. I included 2.4.17-2.4.23 as an item, because that group are the versions that released within the past year of this particular survey data (that does include the then-current 2.4.23.) The 'Of m.m' - same major.minor - backs out that Apache/2.x (without a known subversion) from the calculation because we can't tell whether they are the corresponding or a different subversion. Of httpd users we can quantify, 6.4% updated within months of the 2.4.23 release (your 'power users' classification.) That minority doesn't move the needle much on total adoption of httpd vs. others. Only 11.3% bothered to pick up the final 2.2.31 that has been out over a year, and combined with 12.74% running some 2.4.17...2.4.23, *** only 24% *** run a version that had been a current release within the preceding year. E.g. of those running a somewhat-current version, more than 1/4 are running the July 2.4.23 release by the end of November. Note that Fedora 25 didn't move the needle much on this, it shipped GA in December. aren't the ones we are talking about in the 1st place. We are > talking about real, "power" users, who want/need the latest > and greatest. > Not if you are talking overall adoption rate. As illustrated, those users adopting 2.4.23 already are an nearly accidental minority, after 5 mos half of the 'current' 2.4 users are running 2.4.23, the other half are running a flavor between 12 and 6 mos old. That looks like overall random distribution by deployment date, with no particular effort expended on 'staying current'.
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
On Wed, Dec 28, 2016 at 9:05 AM, Jan Ehrhardt wrote: > William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50 > -0600): > >But the vast majority of httpd, nginx, and yes - even IIS > >users are all running what they were handed from their > >OS distribution. > > Do not underestimate the influence of control panels. On all my Centos > servers I am running Directadmin. DA always offers to upgrade to the > latest release within a day after the release. Hence, I am running > Apache 2.4.25 everywhere at the moment. > > Excellent pointer. Thanks Jan.
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
cPanel too... They are moving to EA4 which is Apache 2.4. So the idea that supplemental (ie: 2.4.x->2.4.y) patches don't have the reach or range of larger ones (2.4.x->2.6/3.0) isn't quite accurate. IMO, people who are comfortable with "whatever the OS provides" aren't the ones we are talking about in the 1st place. We are talking about real, "power" users, who want/need the latest and greatest. just my 2c > On Dec 28, 2016, at 10:05 AM, Jan Ehrhardt wrote: > > William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50 > -0600): >> But the vast majority of httpd, nginx, and yes - even IIS >> users are all running what they were handed from their >> OS distribution. > > Do not underestimate the influence of control panels. On all my Centos > servers I am running Directadmin. DA always offers to upgrade to the > latest release within a day after the release. Hence, I am running > Apache 2.4.25 everywhere at the moment. > -- > Jan >
Re: The Version Bump fallacy [Was Re: Post 2.4.25]
William A Rowe Jr in gmane.comp.apache.devel (Tue, 27 Dec 2016 23:35:50 -0600): >But the vast majority of httpd, nginx, and yes - even IIS >users are all running what they were handed from their >OS distribution. Do not underestimate the influence of control panels. On all my Centos servers I am running Directadmin. DA always offers to upgrade to the latest release within a day after the release. Hence, I am running Apache 2.4.25 everywhere at the moment. -- Jan
The Version Bump fallacy [Was Re: Post 2.4.25]
On Fri, Dec 23, 2016 at 2:52 PM, Jim Jagielski wrote: > > As I have also stated, my personal belief is that > 2.4 is finally reaching some traction, and if we > "turn off" development/enhancement of 2.4, we will > stop the uptake of 2.4 in its track. This is where I think we have a disconnect. Our adoption is *broadly* based on the OS distributions from vendors, not from people picking up our sources. Yes - some integrate directly from source, and others use a non-OS distribution. But the vast majority of httpd, nginx, and yes - even IIS users are all running what they were handed from their OS distribution. This is why an amazing number of people run 2.4.3-2.4.10 and soon, 2.4.18, even though these are all already out of date. Once RHEL, Ubuntu LTS, SUSE or others pick up a specific rev, that's where the typical user is going to land for the next several years. The raw stats show a couple of interesting things, IMO; https://w3techs.com/technologies/overview/web_server/all While we have slipped somewhat, the old adage that httpd or another "Web Server" must sit in front of the cobbled-together app servers doesn't apply anymore. Code like Tomcat, etc, is now far more robust and capable of sitting on the outward facing edge of the DMZ. The two runners up in web server space have essentially switched places, nginx now has the market penetration that IIS once enjoyed. IIS now amounts to a fraction of what it once did, essentially the 'everything else' share that used to be held by webservers we don't think about any more, such as Sun's, lighttpd, etc. And of course custom server agents of the top 10 data providers skew the results significantly. Other surveys paint the data a little differently; https://news.netcraft.com/archives/2016/12/21/december- 2016-web-server-survey.html http://www.securityspace.com/s_survey/data/201611/index.html Next up, we will see broad distribution of 2.4.23 - why? Because that shipped in Fedora 25 which will very likely become RHEL 8. E.g. we missed the boat, Generally the Fedora release a year out from RHEL GA become the shipping packages, and the pattern suggests this early winter release becomes an early winter '17 RHEL. If we don't ship improvements, we wither and fall into oblivion. It does not matter that these are called 2.4.26 because *no vendor will ship it*. Not until they start gathering the components of their next major release. Which means, they are shipping are least interesting sources over and over because we aren't shipping new major releases. So I'd respectively suggest that adding a feature to 2.4 vs releasing the feature in 3.0 makes not one iota of difference in goodwill/adoption. The next major releases who code freeze after 3.0 has shipped will be in position to pick up and distribute 3.0. All the rest will be stuck in the past. But as a bottom line, all those users stuck in the past until their OS catches up will have little opinion about a feature in a 2.4.x release they will never see, since their vendor keeps shipping the same 2.4.n that their OS revision had initially shipped. .
Re: Post 2.4.25
> On 24 Dec 2016, at 16:32, Eric Covener wrote: > >> I'm not saying we don't do one so we can do the other; I'm >> saying we do both, at the same time, in parallel. I still >> don't understand why that concept is such an anathema to some >> people. > > I also worry about our ability to deliver a 3.0 with enough > re-architecture for us and and function for users, vs a more > continuous delivery (apologies for bringing buzzaords to dev@httpd) > cadence on 2.4 as we've been in. If you can find a way with limited resources, I would encourage doing both in parallel as well. What are the 2.6/3.0 re-architecture goals/vision out of curiosity? - Mark
Re: Post 2.4.25
> I'm not saying we don't do one so we can do the other; I'm > saying we do both, at the same time, in parallel. I still > don't understand why that concept is such an anathema to some > people. I also worry about our ability to deliver a 3.0 with enough re-architecture for us and and function for users, vs a more continuous delivery (apologies for bringing buzzaords to dev@httpd) cadence on 2.4 as we've been in.
Re: Post 2.4.25
On Dec 24, 2016 10:57, "Jim Jagielski" wrote: Yeah, right now the way we are "doing marketing" is by continually adding features and enhancements to 2.4... It is what keeps 2.4 relevant and is what either keeps current httpd users using httpd or maybe help those on the fence decide on httpd instead of nginx/whatever. My point is that even having a 6 month minimal (and that is, IMO, widely optimistic and unrealistic) of "no new features for 2.4" means that we are basically giving people reasons to drop httpd. Oh, sure, I agree with that. Six months of (perceived) inaction would tell the world we're all done. I'm probably answering a different question. :)
Re: Post 2.4.25
> On Dec 24, 2016, at 8:54 AM, Eric Covener wrote: > > On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr > wrote: >> Next step is to actually end enhancements alltogether >> against 2.4 (we've done that some time ago, security >> issues notwithstanding, on 2.2), and push all of the >> enhancement effort towards 3.0 (2.5-dev). Of course, >> we should continue to pick up bug fixes and help those >> still on 2.4 have a good day. >> >> Let those users looking for cool new things pick up >> the 3.0 release. > > What's the carrot for users/developers in a 2.6/3.0? I'm not sure > they'd come along for this ride. To play devils advocate, it seems > like many of the breaking changes could be imposed by having > deprecated fields/accessors (maybe moving to more of the latter) and > preferred alternatives (to avoid major MMN bumps). > Yeah, that is kind of alluded to in my thoughts. For 3.0 to *really* be a major carrot, we are talking (IMO), a major refactoring. A super streamlining of filters, etc. I used to think making use of Serf would be it, but instead I'm thinking libmill/libdill would be better (plus, to be honest, I still can't figure out all the ins and outs of Serf and there's no documentation at all)... In other words, to ensure that people come along for the ride, the ride has to be revolutionary, at least at some level. And that, imo, takes time to architecture, design, implement and test. If we say "no new stuff for 2.4 until then" then, as I have stated, we have given all our current users a great reason and rationale for leaving, and they will. I'm not saying we don't do one so we can do the other; I'm saying we do both, at the same time, in parallel. I still don't understand why that concept is such an anathema to some people. > Anyone with ideas about what they'd want in a new release is > encouraged to add them to the trunk STATUS file, even if they are just > wishlist items -- it's not a commitment. Added some of mine already :)
Re: Post 2.4.25
> On Dec 24, 2016, at 8:29 AM, Rich Bowen wrote: > > > > On 12/23/2016 03:52 PM, Jim Jagielski wrote: >> Personally, I don't think that backporting stuff to >> 2.4 prevents or disallows development on 2.6/3.0. In >> fact, I think it helps. We can easily do both... >> after all, we are still "working" on 2.2. >> >> As I have also stated, my personal belief is that >> 2.4 is finally reaching some traction, and if we >> "turn off" development/enhancement of 2.4, we will >> stop the uptake of 2.4 in its track. We need to keep >> 2.4 viable and worthwhile we, at the same time, work >> on 2.6/3.0. I think we all understand that getting >> 2.6/3.0 out will not be a quick and/or painless >> action. > > From my perspective, watching Nginx gain traction through superior > marketing, and channeling Dilbert's Pointy Haired Boss in assuming that > everything which I have never done must be simple, I, for one, would > like to see us release a 2.6, and more generally, to release a 2.x every > 2 years, or less, rather than every 4 years, or more. > > My opinion on this, I would emphasize, is 100% marketing, and 0% > technical. I realize we "don't do" marketing, but if we want to still ve > having the fun of doing this in another 20 years, it may be necessary to > get our name out there a little more frequently in terms of doing new > things. We are frankly not great at telling the world about the cool new > things we're doing. > Yeah, right now the way we are "doing marketing" is by continually adding features and enhancements to 2.4... It is what keeps 2.4 relevant and is what either keeps current httpd users using httpd or maybe help those on the fence decide on httpd instead of nginx/whatever. My point is that even having a 6 month minimal (and that is, IMO, widely optimistic and unrealistic) of "no new features for 2.4" means that we are basically giving people reasons to drop httpd. It would be a widely different story if (1) trunk was ready to release and (2) we "committed" to releasing trunk quickly by focusing on low-hanging fruit which would make lives happier and better for our end-users. As I said, my fear is that we will not be able to "control" ourselves in limiting what is in 2.6, which will push the actual release far past the point where it is even relevant. To be clear, if our goal was "Fork trunk as 2.5 NOW, polish and tune 2.5 'as-is' with minimal major refactoring with the goal of getting 2.6 out ASAP" then yeah, sure, the idea of "no new features in 2.4" would have some merit. But based on current conversation, it's obvious that, at least to me, that won't happen and we will be continually refactoring 2.6 to make it a 3.0. Again, you don't "stop" development on a current release until the next release is ready or, at least, "this close" to being ready. You don't sacrifice the present, nor do you leave your users in that limbo.
Re: Post 2.4.25
On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr wrote: > Next step is to actually end enhancements alltogether > against 2.4 (we've done that some time ago, security > issues notwithstanding, on 2.2), and push all of the > enhancement effort towards 3.0 (2.5-dev). Of course, > we should continue to pick up bug fixes and help those > still on 2.4 have a good day. > > Let those users looking for cool new things pick up > the 3.0 release. What's the carrot for users/developers in a 2.6/3.0? I'm not sure they'd come along for this ride. To play devils advocate, it seems like many of the breaking changes could be imposed by having deprecated fields/accessors (maybe moving to more of the latter) and preferred alternatives (to avoid major MMN bumps). Anyone with ideas about what they'd want in a new release is encouraged to add them to the trunk STATUS file, even if they are just wishlist items -- it's not a commitment.
Re: Post 2.4.25
On 12/23/2016 03:52 PM, Jim Jagielski wrote: > Personally, I don't think that backporting stuff to > 2.4 prevents or disallows development on 2.6/3.0. In > fact, I think it helps. We can easily do both... > after all, we are still "working" on 2.2. > > As I have also stated, my personal belief is that > 2.4 is finally reaching some traction, and if we > "turn off" development/enhancement of 2.4, we will > stop the uptake of 2.4 in its track. We need to keep > 2.4 viable and worthwhile we, at the same time, work > on 2.6/3.0. I think we all understand that getting > 2.6/3.0 out will not be a quick and/or painless > action. From my perspective, watching Nginx gain traction through superior marketing, and channeling Dilbert's Pointy Haired Boss in assuming that everything which I have never done must be simple, I, for one, would like to see us release a 2.6, and more generally, to release a 2.x every 2 years, or less, rather than every 4 years, or more. My opinion on this, I would emphasize, is 100% marketing, and 0% technical. I realize we "don't do" marketing, but if we want to still ve having the fun of doing this in another 20 years, it may be necessary to get our name out there a little more frequently in terms of doing new things. We are frankly not great at telling the world about the cool new things we're doing. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon signature.asc Description: OpenPGP digital signature
Re: Post 2.4.25
On Dec 23, 2016 9:58 PM, "Jim Jagielski" wrote: Well, since I am actively working on trunk, I am obviously interested in seeing continued work being done on it and the work being usable to our users in a timely fashion. Since backports to 2.2 have not affected work on 2.4 or trunk, it is obvious as well that any backport efforts for 2.4 won't be any issue at all, so work on trunk will be unrestricted. Restrictions, no, never. But if I had to ask how did that work out for me merging antique commits back at 2.4 and from 2.4 to 2.2, you don't want my opinion on your therom. I hope your enthusiasm regarding timeframes is warranted and accurate. Obviously my efforts are directed towards what is best for our community and am looking forward to how we continue with next gen. As do I. Different refutation of your underlying therom on versioning will happen on or after the weekend. In the meantime... A joyous belated Solstice, happy Hanukkah, merry Christmas, or just wishing everyone a good weekend. You have all been some of.my most favorite people now for 15+ years. See you all next year :)
Re: Post 2.4.25
> On Dec 23, 2016, at 5:50 PM, William A Rowe Jr wrote: > > Just a couple quick thoughts... > > On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote: > > . We need to keep > 2.4 viable and worthwhile > > So long as we fix the bugs, it is. > Personally, especially considering the current landscape, I believe that statement is simply wrong. Saying "just bug fixes" for 2.4 for some unknown number of months is just flat out incorrect when we haven't even EOLed it and, in fact, when 2.2 is still available, supported and would be in that self- same mode. "actually end enhancements alltogether against 2.4" at this point is a sure fire way to completely kill Apache httpd and is not required in the least. You seem to forget that people can, and want, to do both. We do not, and should not, control and restrict, without very good, solid, reasons, what people do on their own free time here. Just as it is "unwise" or "authoritarian" to "block" work on trunk, it is the same for 2.4, considering the situation that we are in *right now*. We need to continue to be relevant and innovative in 2.4 while we are, at the same time, creating the next rev. Suffocating one before its "replacement" is even in pre-alpha stage is simply not needed nor is it a wise move project-management-wise. It is unfair to our users. It's like saying you can't have another kid until your youngest is 18 :) Cheers.
Re: Post 2.4.25
Well, since I am actively working on trunk, I am obviously interested in seeing continued work being done on it and the work being usable to our users in a timely fashion. Since backports to 2.2 have not affected work on 2.4 or trunk, it is obvious as well that any backport efforts for 2.4 won't be any issue at all, so work on trunk will be unrestricted. I hope your enthusiasm regarding timeframes is warranted and accurate. Obviously my efforts are directed towards what is best for our community and am looking forward to how we continue with next gen. On 2016-12-23 17:50 (-0500), William A Rowe Jr wrote: > Just a couple quick thoughts... > > On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote: > > > As I have also stated, my personal belief is that > 2.4 is finally reaching some traction, and if we > "turn off" development/enhancement of 2.4, we will > stop the uptake of 2.4 in its track. > > > I think you might be misconstruing our flaws in httpd with our version > numbering scheme. > > There is only one other project with our longevity that refuses to bump > version majors, and they are suddenly 2 versions ahead of us in only a few > short years. If you haven't guessed, that's the Linux Kernel. > > > . We need to keep > 2.4 viable and worthwhile > > > So long as we fix the bugs, it is. > > Maybe the whole thing revolves around us mistakenly > using the term "2.6/3.0"... > > > I ceased doing this. After another admonishment that version numbers are > cheap, and out team's concensus that treating r->uri as a decoded value was > a wrong call, we won't have a release that can be called 2.next. > > During its incubation of alphas and betas, it still remains 2.5.x, but on > completion I can't imagine calling this 2.6. This will be a fundamental > change that requires a 3.0 designation. > > I don't see us taking shortcuts to get to that point, but believe it is a > change that will occur in a very short timespan, because several committers > want to see this happen. > > So long as it is foretold that nobody is blocking 3.0, unlike 3 years ago, > I expect that sort of energy and enthusiasm to take hold toward a GA > release in the next six months, if we don't get bogged down in more > backport type of activity. >
Re: Post 2.4.25
Just a couple quick thoughts... On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote: As I have also stated, my personal belief is that 2.4 is finally reaching some traction, and if we "turn off" development/enhancement of 2.4, we will stop the uptake of 2.4 in its track. I think you might be misconstruing our flaws in httpd with our version numbering scheme. There is only one other project with our longevity that refuses to bump version majors, and they are suddenly 2 versions ahead of us in only a few short years. If you haven't guessed, that's the Linux Kernel. . We need to keep 2.4 viable and worthwhile So long as we fix the bugs, it is. Maybe the whole thing revolves around us mistakenly using the term "2.6/3.0"... I ceased doing this. After another admonishment that version numbers are cheap, and out team's concensus that treating r->uri as a decoded value was a wrong call, we won't have a release that can be called 2.next. During its incubation of alphas and betas, it still remains 2.5.x, but on completion I can't imagine calling this 2.6. This will be a fundamental change that requires a 3.0 designation. I don't see us taking shortcuts to get to that point, but believe it is a change that will occur in a very short timespan, because several committers want to see this happen. So long as it is foretold that nobody is blocking 3.0, unlike 3 years ago, I expect that sort of energy and enthusiasm to take hold toward a GA release in the next six months, if we don't get bogged down in more backport type of activity.
Re: Post 2.4.25
Personally, I don't think that backporting stuff to 2.4 prevents or disallows development on 2.6/3.0. In fact, I think it helps. We can easily do both... after all, we are still "working" on 2.2. As I have also stated, my personal belief is that 2.4 is finally reaching some traction, and if we "turn off" development/enhancement of 2.4, we will stop the uptake of 2.4 in its track. We need to keep 2.4 viable and worthwhile we, at the same time, work on 2.6/3.0. I think we all understand that getting 2.6/3.0 out will not be a quick and/or painless action. Maybe the whole thing revolves around us mistakenly using the term "2.6/3.0"... I seen trunk as something that could become 2.6 in "short order", if that's the direction we want to go. But there is also the need and desire to really clean-up the codebase (r->uri is the common example used), which means a codebase which is more 3.0 related, and therefore, more extensive and thus taking more time. However, by us using the term "2.6/3.0" it muddies the water, and implies that 2.6 could be much more pervasive that it already is. The long and short is that there is good stuff in trunk. It should be available to our users sooner rather than later. If you want to call that 2.6, fine. What I don't want to see, since I don't think it is a viable solution, is for us to say "OK, let's tag trunk as 2.5 with the goal of getting 2.6 out soon... But hold on, this is broken and we need to completely refactor this. And this is weird, let's strip this out and replace it with this... And while we are at it, let's change this to do that" with the end result that 2.5/2.6 takes ages and 2.4 is left fallow. And, to be honest, I think that is exactly what will happen. The turd will never be polished enuff. And our community suffers. So, to make it crystal clear, I am 100% FOR httpd-next-gen. All I am saying is that we have an existing user base which is still mostly on 2.2, much less 2.4, and they are currently at a disadvantage by not having access to the latest and greatest stuff which is locked away in trunk and could be available for them, *while httpd-next-gen is being worked in parallel*. Nothing is preventing people from playing on trunk... But my feeling is that most people like hacking code that people eventual run in short order and in a timely timeframe. Waiting 6-12-18 months for "new features" is how commercial s/w works, not FOSS. https://w3techs.com/technologies/details/ws-apache/2/all I will ignore the likelihood that httpd-next-gen will require APR 2.0 which may also take a long time to be released. > On Dec 23, 2016, at 3:28 PM, William A Rowe Jr wrote: > > On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski wrote: > For me, it would be moving as much as we can from > trunk to 2.4 > > -1. To echo your frequent use of media to emphasize > the point, with a song nearly as old as us; > https://www.youtube.com/watch?v=EsCyC1dZiN8 > > Next step is to actually end enhancements alltogether > against 2.4 (we've done that some time ago, security > issues notwithstanding, on 2.2), and push all of the > enhancement effort towards 3.0 (2.5-dev). Of course, > we should continue to pick up bug fixes and help those > still on 2.4 have a good day. > > Let those users looking for cool new things pick up > the 3.0 release. > > Or else you are kicking 'everything we can't' further > down the road, again dismissing all of the activity > of so many of our fellow committers. Stale stuff on > trunk/ now dates to over 4 years ago. > > That state of things simply sucks. >
Re: Post 2.4.25
On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski wrote: > For me, it would be moving as much as we can from > trunk to 2.4 -1. To echo your frequent use of media to emphasize the point, with a song nearly as old as us; https://www.youtube.com/watch?v=EsCyC1dZiN8 Next step is to actually end enhancements alltogether against 2.4 (we've done that some time ago, security issues notwithstanding, on 2.2), and push all of the enhancement effort towards 3.0 (2.5-dev). Of course, we should continue to pick up bug fixes and help those still on 2.4 have a good day. Let those users looking for cool new things pick up the 3.0 release. Or else you are kicking 'everything we can't' further down the road, again dismissing all of the activity of so many of our fellow committers. Stale stuff on trunk/ now dates to over 4 years ago. That state of things simply sucks.
Post 2.4.25
Now that we have 2.4.25 done, I'd like us to take the next few weeks thinking about how we'd like to see the next release shape up. For me, it would be moving as much as we can from trunk to 2.4, again, to enable current users to leverage and enjoy the goodness which is currently "stuck" in trunk. Some can be backported, some can't of course, but it seems wise to try to backport what we can. Other stuff, like brotli, seem low-hanging-fruit which is ready to be plucked. We should also, now that 2.4.25 is out with fixes/work- arounds for some issues, tighten them up as needed. No rush, of course, but assuming that many of us have the next week or so as some "time off", it might be a good opportunity for us to spend some of our own time thinking what's next.