Re: The Version Bump fallacy [Was Re: Post 2.4.25]

[Jim Jagielski]

> 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]

[William A Rowe Jr]

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]

[Noel Butler]

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]

[William A Rowe Jr]

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]

[Jim Jagielski]

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

[David Zuelke]

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

[Stefan Fritsch]

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]

[Houser, Rick]

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
> > <wr...@rowe-clan.net <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]

[Daniel Ruggeri]

On 12/28/2016 6: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.
>
> - 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

[William A Rowe Jr]

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]

[William A Rowe Jr]

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]

[Jim Jagielski]

> 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]

[Jim Jagielski]

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

[Jim Jagielski]

> 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

[Reindl Harald]

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]

[Stefan Eissing]

> 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]

[William A Rowe Jr]

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

[Yann Ylavic]

[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]

[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.

- Y

Re: Post 2.4.25

[William A Rowe Jr]

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

[William A Rowe Jr]

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]

[William A Rowe Jr]

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]

[William A Rowe Jr]

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]

[Jim Jagielski]

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]

[Jan Ehrhardt]

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]

[William A Rowe Jr]

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]

[William A Rowe Jr]

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]

[Jim Jagielski]

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]

[Jan Ehrhardt]

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]

[William A Rowe Jr]

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

[Mark Blackman]

> 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

[Eric Covener]

> 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

[Rich Bowen]

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

[Jim Jagielski]

> 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

[Jim Jagielski]

> 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

[Eric Covener]

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

[Rich Bowen]

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

[William A Rowe Jr]

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

[Jim Jagielski]

> 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

[Jim Jagielski]

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

[Jim Jagielski]

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

[William A Rowe Jr]

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

[Jim Jagielski]

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.