Re: PMC Reporting [Was: Re: 2.2 and 2.4 and 2.6/3.0]
On 5/30/2015 9:03 PM, William A Rowe Jr wrote: So I'll let Eric share what he submitted for May on our behalf, but here is the submitted/accepted/recorded report of Feb '15 - it's awfully high level, so I'm not sure that updating dev@ regularly with the contents offers a whole lot of benefit. Thoughts? Yeah - The information seems great to share with the community behind httpd, IMO, so I think it would make sense to have on the dev@ list... and it's not like this is a particularly low volume mailing list that such emails would be considered inbox pollution. I guess it's just as easy to pull up the minutes each month by hand, too. -- Daniel Ruggeri
Re: PMC Reporting [Was: Re: 2.2 and 2.4 and 2.6/3.0]
There's usually just not much to it. Here's what was last submitted: Report from the Apache HTTP Server project [Eric Covener] ## Description: The Apache HTTP Server Project develops and maintains an open-source HTTP server for modern operating systems. ## Activity: Overall project activity is low, with various fixes being made on maintenance releases but very little forward development. Third-party work on an HTTP/2 module was discussed more this reporting period, with some enablement work for ALPN revived in mod_ssl. No security issues have required new releases, so patches have collected a little longer than normal in the stable releases. ## Issues: There are no issues requiring board attention at this time. ## PMC/Committership changes: - Currently 112 committers and 43 PMC members in the project. - Christophe Jaillet was added to the PMC on Mon Mar 09 2015 - Stefan Sperling was added as a committer on Fri Apr 17 2015 ## Releases: - Last 2.4.x release was 2.4.12 on Jan 26 2015 - Last 2.2.x release was 2.2.29 on September 3 2014 On Mon, Jun 1, 2015 at 8:14 PM Daniel Ruggeri drugg...@primary.net wrote: On 5/30/2015 9:03 PM, William A Rowe Jr wrote: So I'll let Eric share what he submitted for May on our behalf, but here is the submitted/accepted/recorded report of Feb '15 - it's awfully high level, so I'm not sure that updating dev@ regularly with the contents offers a whole lot of benefit. Thoughts? Yeah - The information seems great to share with the community behind httpd, IMO, so I think it would make sense to have on the dev@ list... and it's not like this is a particularly low volume mailing list that such emails would be considered inbox pollution. I guess it's just as easy to pull up the minutes each month by hand, too. -- Daniel Ruggeri
Re: 2.2 and 2.4 and 2.6/3.0
On 5/30/2015 1:47 PM, Daniel Ruggeri wrote: Thinking about this more, what are the things preventing people from an _easy_ upgrade path configuration-wise? A lot of this conversation surrounded users and the impact of an upgrade to them. The interface for the users' to the server is the configuration file. Maybe if we can tackle that we can greatly reduce a barrier to upgrade (or maybe I'm too optimistic)? For the majority of my configs, it was the changes to the authorization directives - it takes brainpower to figure out what AdminXYZ was trying to do years ago and reflect that with the new directives. However, this is deterministic... a perl script could do this work for me if I'd just write it. At $dayjob, this is the stuff I focus on. Tweaks to an existing script I put together years ago to upgrade from 2.0 to 2.2 (or as Rich eloquently put, poop out new configs) only required an hour's worth of work or so to support upgrades from 2.2 to 2.4 minus the aforementioned authz directives. -- Daniel Ruggeri aand on the original topic at hand, I'll share that none of us are really *forced* to focus on any particular branch or any particular area of the code base. As an army of volunteers, we scratch our own itch. I, too, have noticed that 2.2 hasn't had a whole lot going on lately. I don't know if that means we ought to get ready to drop the axe on it, but I also don't know if that means we shouldn't be thinking about it, either. I think Jim's email served it's purpose of at least vocalizing a thought that's probably in the back of all of our minds: 2.2 isn't getting a ton of love (or at least as much love as 2.4) lately. What that means to each of us is clearly different... for me, I noticed that the effort to backport some of the work I've done in 2.4 doesn't pay off so I don't do it. I haven't put much more thought into 2.2 than that. For others it might be a push to backport more stuff. At the same time, Bill points out a reality we're faced with. As the most widely deployed HTTP server, we have some sort of responsibility (whether real or imagined) to the users not to cut them off if we can avoid it. The point about distros taking their sweet time to update are well taken - it's one of the reasons I always build from latest source. Maybe there's a reason other than inertia for the slow adoption. Their own lack of volunteer cycles? Configuration differences? Performance differences? What we have works, so why change it? Do we know those reasons enough to try to keep ahead of them? P.S. I'm not a Member or PMC... do I have access to the report that spurred the conversation? P.P.S. Wow... I don't read my email for a few days... -- Daniel Ruggeri
Re: 2.2 and 2.4 and 2.6/3.0
On 5/28/2015 2:54 PM, Jim Riggs wrote: Having to expend effort (e.g. re-design/update config and deployment) to switch/update/upgrade to a new paradigm does not, IMO, mean that it's not a solution for everyone. Anyone can take the time to implement and automate the switch. Once that effort has been spent, you should have nearly the same (maybe better) setup, with hopefully better security and resource utilization in many cases. All of those php_admin_* directives end up in a php-fpm conf file that can easily be automatically updated and deployed. Thinking about this more, what are the things preventing people from an _easy_ upgrade path configuration-wise? A lot of this conversation surrounded users and the impact of an upgrade to them. The interface for the users' to the server is the configuration file. Maybe if we can tackle that we can greatly reduce a barrier to upgrade (or maybe I'm too optimistic)? For the majority of my configs, it was the changes to the authorization directives - it takes brainpower to figure out what AdminXYZ was trying to do years ago and reflect that with the new directives. However, this is deterministic... a perl script could do this work for me if I'd just write it. At $dayjob, this is the stuff I focus on. Tweaks to an existing script I put together years ago to upgrade from 2.0 to 2.2 (or as Rich eloquently put, poop out new configs) only required an hour's worth of work or so to support upgrades from 2.2 to 2.4 minus the aforementioned authz directives. -- Daniel Ruggeri
Re: 2.2 and 2.4 and 2.6/3.0
On 27 May 2015, at 13:54, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... Depends on what EOL means practically, of course. As someone whose day job is engineering the web platform for one of the big investment banks, I can tell you we only just got everyone moved over to 2.2 (i.e. several years after 1.3 got canned in early 2010). So while I’m not looking for the latest and greatest features in 2.2 at this stage, I do want to continue to see bug fixes and security issues addressed for at least another five years (ideally), and really 2 years at a minimum. I can easily see this might be asking too much of volunteers, but those are my “enterprise” expectations. - Mark
PMC Reporting [Was: Re: 2.2 and 2.4 and 2.6/3.0]
On Sat, May 30, 2015 at 2:14 PM, Daniel Ruggeri drugg...@primary.net wrote: P.S. I'm not a Member or PMC... do I have access to the report that spurred the conversation? Adding the context back to the thread... On Wed, May 27, 2015 at 11:32 AM, Jim Jagielski j...@jagunet.com wrote: FWIW: It was this month's PMC status report which kind of spurred this email. Yes. The Monthly Board of Directors meeting minutes do become public. All of the following ASF documents are a matter of public record; http://www.apache.org/foundation/records/ and you'll find the _Board Calendar and Minutes_ as the fifth link listed on that page. Following through to the minutes, as of this moment, minutes are only current up to March, several months ago, but that is because they are reviewed by any officer attending and all board board member for errors and omissions before they are approved at a subsequent meeting. So this will be 1-90 days out of sync, occasionally longer. As far as our report submitted to the board each quarter - and included in the foundation board minutes, the last published already was Feb '15, so the subsequent one is last month, May '15 and should show up in another month or two. In theory, it isn't our report until 1. it is submitted, the board 2. considers and 3. accepts the report at their meeting (a few weeks ago), and 4. accepts the minutes of their meeting as recorded :) So I'll let Eric share what he submitted for May on our behalf, but here is the submitted/accepted/recorded report of Feb '15 - it's awfully high level, so I'm not sure that updating dev@ regularly with the contents offers a whole lot of benefit. Thoughts? Attachment AL: Report from the Apache HTTP Server Project [Eric Covener] Project Description === The Apache HTTP Server Project develops and maintains an open-source HTTP server for modern operating systems. Issues for the Board There are no outstanding issues that require the board's attention. Releases * 2.4.12 : Released on January 29, 2014 Older branches last release: * 2.2.x: 2.2.29 released September 3 2014 * 2.0.x(EOL) 2.0.65 released July 9, 2013 Bug Activity * 164 bugs worked on, 60 new, 71 closed/fixed Community = * Yann Ylavic was added to the PMC. * Date of last new committer : October 2014 (Steve Hay) * Date of last new PMC member: February 2015 (Yann Ylavic) * Overall development activity continues to slow, with the focus on security fixes andthe maintenance of 2.4.x which is making its way into various httpd distributions. * Thanks to Rich Bowen for organizing a httpd/TS/Tomcat track for ACNA 2015.
Re: 2.2 and 2.4 and 2.6/3.0
On Thu, May 28, 2015 at 3:45 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On May 27, 2015 9:46 AM, Jeff Trawick traw...@gmail.com wrote: On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick traw...@gmail.com wrote: On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... People here focus their energy on whatever they want. It takes a small number of people to keep a stable branch going (technically 3, but in practice a slightly higher number). Instead of the group choosing EOL or only-security-fixes-of-some-minimal-severity or something else for a stable branch based on what many people think is interesting to them for whatever reason, I think that the project should limit its concern to ensuring that the community understands the state of the branch and that it is EOL-ed when a sufficient number of people don't care. actually, when a sufficient number of people don't care is what I'm arguing against :) make that when an insufficient number of people care +1, well thought out, aligns with the historical commentary (just some of which I pointed out in the historical data points post) What we need to know for the 2.2.x branch is basically this: Developers (committers or not): [ X ] I am willing to help resolve security issues in the 2.2.x branch. [ X ] I am willing to help address non-security issues in the 2.2.x branch. PMC members: [ X ] I am willing to test and vote on proposed 2.2.x releases. (This is not a call for vote; I'm suggesting a very different mindset towards 2.2.x from nice to focus energy on and time to EOL 2.2 and focus on.) (: Glad that others felt free to respond to this as a poll. :) The pseudo-poll was the clearest way I could think of to lay out my opinion of what I think our criteria should be, and I didn't want to come across as antagonistic anyway (random-emoticon) But the several responses are useful information. Cut and paste at will! I think there is a story in all of this for the greater community about our (?) particular take on an open source project, pros and cons for * individual developers * different classes of users * the httpd-of-Christmas-future, our strong desire avoid unplanned obsolescence, our willingness to empower even potentially small subsets of our developer community, etc. (Meanwhile, somebody pinged me about mod_fcgid recently; apparently there is some low-hanging fruit in Bugzilla and no any recent activity :( ) -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: 2.2 and 2.4 and 2.6/3.0
On 05/28/2015 03:54 PM, Jim Riggs wrote: On 28 May 2015, at 14:30, Reindl Harald h.rei...@thelounge.net wrote: Am 28.05.2015 um 21:22 schrieb Rich Bowen: On 05/27/2015 05:38 PM, olli hauer wrote: - for long time there was no working mod_php module for 2.4, and changing to php-fpm was not for everyone a solution. In my experience, the only reason that php-fpm wasn't a solution for everyone is that it was poorly documented. We could still stand to do better there, but php-fpm is, in fact, a solution for everyone no, because it does not support php_admin_flag and php_admin_value inside of Directory and so would require re-design environments with many hundrets of vhosts running for many years that way with automatic deployment of such rules depending on the target application Having to expend effort (e.g. re-design/update config and deployment) to switch/update/upgrade to a new paradigm does not, IMO, mean that it's not a solution for everyone. Anyone can take the time to implement and automate the switch. Once that effort has been spent, you should have nearly the same (maybe better) setup, with hopefully better security and resource utilization in many cases. All of those php_admin_* directives end up in a php-fpm conf file that can easily be automatically updated and deployed. I'm certainly not saying that this work is trivial with many years of history, and it may not be for everyone, but it is certainly possible for anyone. With fpm and mod_proxy_fcgi, I don't see myself ever using mod_php again, but that's just me. It would be worth providing a bash/perl/python script that one could point at your config files and/or .htaccess files and poop out php-fpm conf files as part of the documentation. The advantages of moving from mod_php to php-fpm are not extolled enough. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: 2.2 and 2.4 and 2.6/3.0
More data points and history to ponder, with placeholders to reflect the passage of time; 1998-06-06 Initial 1.3.0 Release 1999-03-24 Stable 1.3.6 Release (last major MMN bump) 2000 2001 2002-04-05 Initial 2.0.35 Release 2002-09-24 Stable 2.0.42 Release (last major MMN bump) 2003 2004 2005-12-01 Initial 2.2.0 Release 2006 2007 2008 2009 2010-02-02 Final 1.3.42 Release 2011-02-02 End of 1.3.xx Life (security patches) 2012-02-21 Initial 2.4.1 Release 2013-02-21 End of 2.0.xx Life (originally planned) 2013-07-09 Final 2.0.65 Release, true EOL 2014 -??-?? Initial 2.6.0/3.0.0 Release -??-?? Final 2.2.?? Release 1.3 Lifespan; ~11 Years - ~8 Years overlap w/ 2.0 (+1 year of security attention/patches) 2.0 Lifespan; ~11 Years - ~8 Years overlap w/ 2.2 2.2 Current clock 9 1/2 years, ~3 Years overlap w/ 2.4 Largest difference? 2.4 arrived 3 years later than the 2.0, 2.2 cadence. Nov 2004 discussion of an EOL Policy for 2.0; http://markmail.org/message/sbddhnoxnz36howj?q=+end+of+life+httpd+1%2E3+list:org%2Eapache%2Ehttpd%2Edevpage=3 State of the 1.3 ecosystem when voting to deprecate in Jan 2010; http://markmail.org/message/z34jplaw2vk2mfsk?q=end+of+life+httpd+1%2E3+list:org%2Eapache%2Ehttpd%2Edev Discussion of the EOL of 2.0 in Sept 2011; http://markmail.org/message/hyf72mrrgggjk4ij?q=apache+httpd+2%2E0+end+of+life The 1.3.42 Announcement/EOL statement http://markmail.org/message/her5q6wcmvvv42tr?q=apache+httpd+1%2E3%2E42+announce The 2.0.65 Announcement/EOL statement; http://markmail.org/message/kkgtum56qfqi6xix?q=apache+httpd+2%2E0%2E65+announce On Thu, May 28, 2015 at 1:25 PM, Houser, Rick rick.hou...@us.pgds.com wrote: Mageia: Mageia 3 released with Apahe 2.4 in April 2013 Apache 2.2 (via Mageia 2) reached EOL in November 2013
Re: 2.2 and 2.4 and 2.6/3.0
Am 28.05.2015 um 21:22 schrieb Rich Bowen: On 05/27/2015 05:38 PM, olli hauer wrote: - for long time there was no working mod_php module for 2.4, and changing to php-fpm was not for everyone a solution. In my experience, the only reason that php-fpm wasn't a solution for everyone is that it was poorly documented. We could still stand to do better there, but php-fpm is, in fact, a solution for everyone no, because it does not support php_admin_flag and php_admin_value inside of Directory and so would require re-design environments with many hundrets of vhosts running for many years that way with automatic deployment of such rules depending on the target application signature.asc Description: OpenPGP digital signature
Re: 2.2 and 2.4 and 2.6/3.0
On 05/27/2015 05:38 PM, olli hauer wrote: - for long time there was no working mod_php module for 2.4, and changing to php-fpm was not for everyone a solution. In my experience, the only reason that php-fpm wasn't a solution for everyone is that it was poorly documented. We could still stand to do better there, but php-fpm is, in fact, a solution for everyone. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon
Re: 2.2 and 2.4 and 2.6/3.0
On 28 May 2015, at 14:30, Reindl Harald h.rei...@thelounge.net wrote: Am 28.05.2015 um 21:22 schrieb Rich Bowen: On 05/27/2015 05:38 PM, olli hauer wrote: - for long time there was no working mod_php module for 2.4, and changing to php-fpm was not for everyone a solution. In my experience, the only reason that php-fpm wasn't a solution for everyone is that it was poorly documented. We could still stand to do better there, but php-fpm is, in fact, a solution for everyone no, because it does not support php_admin_flag and php_admin_value inside of Directory and so would require re-design environments with many hundrets of vhosts running for many years that way with automatic deployment of such rules depending on the target application Having to expend effort (e.g. re-design/update config and deployment) to switch/update/upgrade to a new paradigm does not, IMO, mean that it's not a solution for everyone. Anyone can take the time to implement and automate the switch. Once that effort has been spent, you should have nearly the same (maybe better) setup, with hopefully better security and resource utilization in many cases. All of those php_admin_* directives end up in a php-fpm conf file that can easily be automatically updated and deployed. I'm certainly not saying that this work is trivial with many years of history, and it may not be for everyone, but it is certainly possible for anyone. With fpm and mod_proxy_fcgi, I don't see myself ever using mod_php again, but that's just me.
Re: 2.2 and 2.4 and 2.6/3.0
On May 27, 2015 9:46 AM, Jeff Trawick traw...@gmail.com wrote: On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick traw...@gmail.com wrote: On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... People here focus their energy on whatever they want. It takes a small number of people to keep a stable branch going (technically 3, but in practice a slightly higher number). Instead of the group choosing EOL or only-security-fixes-of-some-minimal-severity or something else for a stable branch based on what many people think is interesting to them for whatever reason, I think that the project should limit its concern to ensuring that the community understands the state of the branch and that it is EOL-ed when a sufficient number of people don't care. actually, when a sufficient number of people don't care is what I'm arguing against :) make that when an insufficient number of people care +1, well thought out, aligns with the historical commentary (just some of which I pointed out in the historical data points post) What we need to know for the 2.2.x branch is basically this: Developers (committers or not): [ X ] I am willing to help resolve security issues in the 2.2.x branch. [ X ] I am willing to help address non-security issues in the 2.2.x branch. PMC members: [ X ] I am willing to test and vote on proposed 2.2.x releases. (This is not a call for vote; I'm suggesting a very different mindset towards 2.2.x from nice to focus energy on and time to EOL 2.2 and focus on.) (: Glad that others felt free to respond to this as a poll.
RE: 2.2 and 2.4 and 2.6/3.0
Mageia: Mageia 3 released with Apahe 2.4 in April 2013 Apache 2.2 (via Mageia 2) reached EOL in November 2013
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 1:41 PM, William A Rowe Jr wr...@rowe-clan.net wrote: Ubuntu - 14.04 LTS, and Debian 8 (Jessie) got the message, a year ago April. RHEL / CentOS 7 aren't even a year old yet. OpenSUSE 13.1 beat them all to the punch, back in Nov of '13. So that's the oldest distribution GA that I've found, perhaps Fedora beat that? To round out, but by no means complete this survey, Fedora 18 shipped 1-15-13, so it in fact beat OpenSuSE GA by 10 months (if you consider a fedora release a 'release' - shrug).
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, 2015-05-27 at 22:42 +0200, Stefan Eissing wrote: Not wanting to boast, but maybe mod_h2 for httpd 2.4 can play a role in motivating people to migrate away from 2.2. I've just looked at your internals page (which seems to me an excellent piece of work), and it tends to support the gut feeling that mod_h2 might be better targeting 2.6/3.0 than 2.4. We should be joining forces to address the issues you've encountered, from minor tweaks to core to more fundamental issues like bucket alloc across threads (or a suitable alternative). Time for me to download and take a proper look at your work, and put my money (or at least timeeffort) where my mouth is! -- Nick Kew
Re: 2.2 and 2.4 and 2.6/3.0
On 28 May 2015, at 4:46 PM, Jim Jagielski j...@jagunet.com wrote: My thoughts are that we use mod_h2 as a guide to how to better implement things in trunk, but also allow for mod_h2 to also work w/ 2.4 as well... So there will be a 2.4 version of mod_h2 as well as a more significant merging of mod_h2/trunk/2.6/3.0. I propose we - where possible - add the missing bits that mod_h2 has to hack around, and then propose those changes for backport to v2.4 in the normal way. Given the amount of inertia minor versions of httpd have, it would be ideal if mod_h2 could be used in the httpd v2.4 timeframe, rather than being forced to wait for v2.6. Obviously if there is anything majorly incompatible that we’ll struggle with then the choice will be made for us, but we should try get mod_h2 usable with v2.4 if that can possibly be achieved. Regards, Graham —
Re: 2.2 and 2.4 and 2.6/3.0
That makes most sense to me as well. Besides all the non-optimal things I discuss in the internals paper, the numbers - of my very limited measurements - show that mod_h2 is slightly less performant than plain httpd *if you only have a single request/connection at a time*. If you have 2 requests ongoing you break even or are slightly better. And then it grows up to 50% more requests/sec than with HTTP/1.1 (all measured over TLS). Of course this varies with resource size and such... Since browsers will typically want to get quite some resources from the server for a page, this should already in 2.4 bring benefit for everyone. cheers, Stefan Am 28.05.2015 um 16:46 schrieb Jim Jagielski j...@jagunet.com: My thoughts are that we use mod_h2 as a guide to how to better implement things in trunk, but also allow for mod_h2 to also work w/ 2.4 as well... So there will be a 2.4 version of mod_h2 as well as a more significant merging of mod_h2/trunk/2.6/3.0. On May 28, 2015, at 10:36 AM, Nick Kew n...@apache.org wrote: On Wed, 2015-05-27 at 22:42 +0200, Stefan Eissing wrote: Not wanting to boast, but maybe mod_h2 for httpd 2.4 can play a role in motivating people to migrate away from 2.2. I've just looked at your internals page (which seems to me an excellent piece of work), and it tends to support the gut feeling that mod_h2 might be better targeting 2.6/3.0 than 2.4. We should be joining forces to address the issues you've encountered, from minor tweaks to core to more fundamental issues like bucket alloc across threads (or a suitable alternative). Time for me to download and take a proper look at your work, and put my money (or at least timeeffort) where my mouth is! -- Nick Kew green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: 2.2 and 2.4 and 2.6/3.0
please dont sent other mail Arash.S Sent from 〰〰 On May 28, 2015, at 3:46 PM, Jim Jagielski j...@jagunet.com wrote: My thoughts are that we use mod_h2 as a guide to how to better implement things in trunk, but also allow for mod_h2 to also work w/ 2.4 as well... So there will be a 2.4 version of mod_h2 as well as a more significant merging of mod_h2/trunk/2.6/3.0. On May 28, 2015, at 10:36 AM, Nick Kew n...@apache.org wrote: On Wed, 2015-05-27 at 22:42 +0200, Stefan Eissing wrote: Not wanting to boast, but maybe mod_h2 for httpd 2.4 can play a role in motivating people to migrate away from 2.2. I've just looked at your internals page (which seems to me an excellent piece of work), and it tends to support the gut feeling that mod_h2 might be better targeting 2.6/3.0 than 2.4. We should be joining forces to address the issues you've encountered, from minor tweaks to core to more fundamental issues like bucket alloc across threads (or a suitable alternative). Time for me to download and take a proper look at your work, and put my money (or at least timeeffort) where my mouth is! -- Nick Kew
Re: 2.2 and 2.4 and 2.6/3.0
My thoughts are that we use mod_h2 as a guide to how to better implement things in trunk, but also allow for mod_h2 to also work w/ 2.4 as well... So there will be a 2.4 version of mod_h2 as well as a more significant merging of mod_h2/trunk/2.6/3.0. On May 28, 2015, at 10:36 AM, Nick Kew n...@apache.org wrote: On Wed, 2015-05-27 at 22:42 +0200, Stefan Eissing wrote: Not wanting to boast, but maybe mod_h2 for httpd 2.4 can play a role in motivating people to migrate away from 2.2. I've just looked at your internals page (which seems to me an excellent piece of work), and it tends to support the gut feeling that mod_h2 might be better targeting 2.6/3.0 than 2.4. We should be joining forces to address the issues you've encountered, from minor tweaks to core to more fundamental issues like bucket alloc across threads (or a suitable alternative). Time for me to download and take a proper look at your work, and put my money (or at least timeeffort) where my mouth is! -- Nick Kew
Re: 2.2 and 2.4 and 2.6/3.0
On May 28, 2015, at 10:51 AM, Graham Leggett minf...@sharp.fm wrote: On 28 May 2015, at 4:46 PM, Jim Jagielski j...@jagunet.com wrote: My thoughts are that we use mod_h2 as a guide to how to better implement things in trunk, but also allow for mod_h2 to also work w/ 2.4 as well... So there will be a 2.4 version of mod_h2 as well as a more significant merging of mod_h2/trunk/2.6/3.0. I propose we - where possible - add the missing bits that mod_h2 has to hack around, and then propose those changes for backport to v2.4 in the normal way. Given the amount of inertia minor versions of httpd have, it would be ideal if mod_h2 could be used in the httpd v2.4 timeframe, rather than being forced to wait for v2.6. I 100% agree! There is stuff that needs to be hacked around in 2.4 but would be somewhat easy to implement (or rather *finish* implementing) in trunk, but would not be backportable. Obviously if there is anything majorly incompatible that we’ll struggle with then the choice will be made for us, but we should try get mod_h2 usable with v2.4 if that can possibly be achieved. Regards, Graham —
Re: 2.2 and 2.4 and 2.6/3.0
I propose we - where possible - add the missing bits that mod_h2 has to hack around, and then propose those changes for backport to v2.4 in the normal way. Given the amount of inertia minor versions of httpd have, it would be ideal if mod_h2 could be used in the httpd v2.4 timeframe, rather than being forced to wait for v2.6. Obviously if there is anything majorly incompatible that we’ll struggle with then the choice will be made for us, but we should try get mod_h2 usable with v2.4 if that can possibly be achieved. +1, it's too much work for consumers the other way.
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 8:55 AM Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... I think it's an accurate reflection of a mode we're nearly in already, but I think we should still be rolling up security releases of 2.2.x for some time. Is there something between legacy and EOL? Maybe just an announcement and a tweak to the description of 2.2.x? I also think if we choose some middle ground, we don't have to announce with any kind of delay.
Re: 2.2 and 2.4 and 2.6/3.0
No issue for me. How many time would bug/security fixes would still be backported (from when we decide so)? On Wed, May 27, 2015 at 2:54 PM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later...
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 12:17 PM, Jim Jagielski j...@jagunet.com wrote: No need to go off... Did I? 2.2 has been out for almost 10 years. Irrelevant to the discussion... 2.4 for a bit over 3. That is a LONG time. Specifically, http://svn.apache.org/r1243503 Generally unusable, the next several versions fixed the serious regressions and we had a pretty solid release by 2.4.3/2.4.4 timetable (about 2 1/2 years ago). Given the lag between a release, incorporating it into an alpha of a distribution release, and that distribution going GA, that is a long lag. Ubuntu - 14.04 LTS, and Debian 8 (Jessie) got the message, a year ago April. RHEL / CentOS 7 aren't even a year old yet. OpenSUSE 13.1 beat them all to the punch, back in Nov of '13. So that's the oldest distribution GA that I've found, perhaps Fedora beat that? So your 'over 3 years' is a pretty gross exaggeration if you are speaking of users as people who get httpd from their OS distribution. I'm simply *suggesting* (no BDFL posturing Mr. Rowe) that after 10 years, maybe it's time to say that 2.2's era is done, and 2.4's time is here, if not already past. And the empirical data says, nope. Nearly 80% of installed httpd is still 2.2. RedHat and the others all have years ahead supporting httpd-2.2. Your suggestion is duly noted and filed :) I'm simply trying to encourage us to work on the future and not focus on the past. No need to read anything more into that, or take on a onerous or holier-than-thou tone. By which your message might be perceived as taking a holier-than-thou tone. Since neither of us would do that, let's move on :) So folks (who don't build themselves) have only had 11 - 18 months to start picking up httpd 2.4, that doesn't seem like the distant past to me, and seems like forever ago to you, that's fine. We are an association of peers with different interests and responsibilities, and have different perspectives on our end user communities. Everything we can do to help them move forward is great. If the insist on running httpd 2.4 on Ubuntu 12.04-LTS or RHEL 5, well... the wiki especially could offer help with that. There are already per-architecture notes and wiki pages. Hopefully they adopt a modern operating system and modern releases of Apache projects across the board. My apologies if Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? was such an egregious question! Shame on me for even asking! :) Ask away! Below was the discussion result last month. I'd expect this to be brought up monthly until maintainers get bored with the dialog and an EOL is pushed through :) On Thu, Apr 2, 2015 at 4:52 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Fri, 13 Mar 2015 08:28:35 +1000 Noel Butler noel.but...@ausics.net wrote: Time to think about EOL'ing 2.2 maybe since its 10 years old and 2.4 has been current stable best production recommendation for what, about 3.5 years or so now, that would see adoption rates grow ;) That would be altogether reasonable, if the currently adopted and still widely supported operating systems shipped 2.4, but it isn't so. While the adoption of 2.2 is all tied into current operating systems, we aren't about to forego security patches to such widely used code. Something to rethink when 2.4 starts to seriously catch up and surpass the 2.2 deployments. The EOL of 2.2 will occur, just as with 2.0, and with 1.3, when you can no longer find a subset of the httpd project members and committers to do any maintenance for the branch. I'm guessing that the inflection point is much closer to 2 years away than 12 months from now.
Re: 2.2 and 2.4 and 2.6/3.0
one thing it means is having compelling stories involving the latest hot tech that use 2.4 basically, any time there is a how-to-FOO somewhere on the www that uses nginx for the web server component, there needs to be a better how-to-FOO that uses httpd 2.4 ;) (I don't even think 2.2 is an issue here) Agreed. Plus the fact that nginx is really open core, and being heavily promoted and marketed by nginx.com, does put httpd, as a real open source project at some disadvantage. We should ping Sally for some thoughts. Also, I know that we could likely get a monthly column from opensource.com (or every other month) to help w/ combating the FUD.
Re: 2.2 and 2.4 and 2.6/3.0
Your thought seems to be that we EOL 2.2 when the number of 2.2 deployments the number of 2.4 ones. My thought is that we EOL 2.2 in order to *hasten* that event, just like just about every other open-source and non-open source software project out there.
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? Nope, we'll let the internet speak for itself - http://w3techs.com/technologies/history_details/ws-apache/2 We are nowhere near close enough to the inflection point of that graph to justify starting the 12 month EOL clock (which has been our traditional countdown, same as the Tomcat project). My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so That sounds about right. I'm personally interested in 3.0 - refactoring on trunk to clean up the evolution of httpd since 2.0.36. That was when we froze MMN majors, so many many bits are now shoehorned into the server in very awkward manners. This will make backports to 2.4 more complex, however. it would be nice to focus energy on 2.4 and later... Focus your energy on anything you like.
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 4:42 PM, Jeff Trawick traw...@gmail.com wrote: On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... People here focus their energy on whatever they want. It takes a small number of people to keep a stable branch going (technically 3, but in practice a slightly higher number). Instead of the group choosing EOL or only-security-fixes-of-some-minimal-severity or something else for a stable branch based on what many people think is interesting to them for whatever reason, I think that the project should limit its concern to ensuring that the community understands the state of the branch and that it is EOL-ed when a sufficient number of people don't care. What we need to know for the 2.2.x branch is basically this: Developers (committers or not): [ ] I am willing to help resolve security issues in the 2.2.x branch. [ ] I am willing to help address non-security issues in the 2.2.x branch. PMC members: [ ] I am willing to test and vote on proposed 2.2.x releases. Looks a sensible approach to me. BTW, I'll/d check all ;)
Re: 2.2 and 2.4 and 2.6/3.0
On 27 May 2015 at 17:42, Jeff Trawick traw...@gmail.com wrote: On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... People here focus their energy on whatever they want. It takes a small number of people to keep a stable branch going (technically 3, but in practice a slightly higher number). Instead of the group choosing EOL or only-security-fixes-of-some-minimal-severity or something else for a stable branch based on what many people think is interesting to them for whatever reason, I think that the project should limit its concern to ensuring that the community understands the state of the branch and that it is EOL-ed when a sufficient number of people don't care. What we need to know for the 2.2.x branch is basically this: Developers (committers or not): [Y ] I am willing to help resolve security issues in the 2.2.x branch. [Y ] I am willing to help address non-security issues in the 2.2.x branch. I'm not Apache HTTP Server committer, but I'm Subversion committer so I'm familiar with httpd code. -- Ivan Zhakov
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick traw...@gmail.com wrote: On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... People here focus their energy on whatever they want. It takes a small number of people to keep a stable branch going (technically 3, but in practice a slightly higher number). Instead of the group choosing EOL or only-security-fixes-of-some-minimal-severity or something else for a stable branch based on what many people think is interesting to them for whatever reason, I think that the project should limit its concern to ensuring that the community understands the state of the branch and that it is EOL-ed when a sufficient number of people don't care. actually, when a sufficient number of people don't care is what I'm arguing against :) make that when an insufficient number of people care What we need to know for the 2.2.x branch is basically this: Developers (committers or not): [ ] I am willing to help resolve security issues in the 2.2.x branch. [ ] I am willing to help address non-security issues in the 2.2.x branch. PMC members: [ ] I am willing to test and vote on proposed 2.2.x releases. Maybe this comes up to the same answer, maybe not. (This is not a call for vote; I'm suggesting a very different mindset towards 2.2.x from nice to focus energy on and time to EOL 2.2 and focus on.) -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: 2.2 and 2.4 and 2.6/3.0
The 2.2.x branch is still of interest to the product I work on. So I am willing to devote effort towards its maintenance. Thanks, Mike On 5/27/2015 7:46 AM, Jeff Trawick wrote: What we need to know for the 2.2.x branch is basically this: Developers (committers or not): [Y] I am willing to help resolve security issues in the 2.2.x branch. [Y] I am willing to help address non-security issues in the 2.2.x branch. PMC members: [ ] I am willing to test and vote on proposed 2.2.x releases.
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so it would be nice to focus energy on 2.4 and later... People here focus their energy on whatever they want. It takes a small number of people to keep a stable branch going (technically 3, but in practice a slightly higher number). Instead of the group choosing EOL or only-security-fixes-of-some-minimal-severity or something else for a stable branch based on what many people think is interesting to them for whatever reason, I think that the project should limit its concern to ensuring that the community understands the state of the branch and that it is EOL-ed when a sufficient number of people don't care. What we need to know for the 2.2.x branch is basically this: Developers (committers or not): [ ] I am willing to help resolve security issues in the 2.2.x branch. [ ] I am willing to help address non-security issues in the 2.2.x branch. PMC members: [ ] I am willing to test and vote on proposed 2.2.x releases. Maybe this comes up to the same answer, maybe not. (This is not a call for vote; I'm suggesting a very different mindset towards 2.2.x from nice to focus energy on and time to EOL 2.2 and focus on.) -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: 2.2 and 2.4 and 2.6/3.0
Focus your energy on anything you like. Can't grok whether that's snarky or not... I'll assume not :)
Re: 2.2 and 2.4 and 2.6/3.0
My point is that if we EOL 2.2 (with some definition of EOL) then people on 2.2 (or earlier) will have some *real* incentive to move off of 2.2 towards 2.4 (or later)... Basically, we need something to kick people off 2.2 and get them to 2.4. By stating that 2.2 will ONLY get security related fixes and no new features or improvements, and that 2.2 will be EOL by 201X, that will be encouragement. That, of course, assumes that we care one way or another about moving people to a more up-to-date and performant httpd, as well as whatever the future holds for httpd. FWIW: It was this month's PMC status report which kind of spurred this email. On May 27, 2015, at 11:34 AM, William A Rowe Jr wr...@rowe-clan.net wrote: On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? Nope, we'll let the internet speak for itself - http://w3techs.com/technologies/history_details/ws-apache/2 We are nowhere near close enough to the inflection point of that graph to justify starting the 12 month EOL clock (which has been our traditional countdown, same as the Tomcat project). My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so That sounds about right. I'm personally interested in 3.0 - refactoring on trunk to clean up the evolution of httpd since 2.0.36. That was when we froze MMN majors, so many many bits are now shoehorned into the server in very awkward manners. This will make backports to 2.4 more complex, however. it would be nice to focus energy on 2.4 and later... Focus your energy on anything you like.
Re: 2.2 and 2.4 and 2.6/3.0
Developers (committers or not): [Y] I am willing to help resolve security issues in the 2.2.x branch. [N] I am willing to help address non-security issues in the 2.2.x branch. PMC members: [Y] I am willing to test and vote on proposed 2.2.x releases. Only security ones. Maybe this comes up to the same answer, maybe not. I know you said this is not a call for a vote, but: :)
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 12:32 PM, Jim Jagielski j...@jagunet.com wrote: My point is that if we EOL 2.2 (with some definition of EOL) then people on 2.2 (or earlier) will have some *real* incentive to move off of 2.2 towards 2.4 (or later)... Basically, we need something to kick people off 2.2 and get them to 2.4. By stating that 2.2 will ONLY get security related fixes and no new features or improvements, and that 2.2 will be EOL by 201X, that will be encouragement. That, of course, assumes that we care one way or another about moving people to a more up-to-date and performant httpd, as well as whatever the future holds for httpd. FWIW: It was this month's PMC status report which kind of spurred this email. crazy and not-so-crazy ideas will speed the movement to 2.4 irrespective of distro schedules (not sure how much :) ) * something like this (and well-publicized) for every Linux distro: https://launchpad.net/~ondrej/+archive/ubuntu/apache2 (I don't think I'm doing many people a favor if I show configure invocations when I talk about 2.4; for most people it isn't a good idea to build httpd themselves) * upgrade Saturdays: IRC 2.2-2.4 upgrade events once a month (not to say that isn't available already, but maybe there are psychological aspects of this that drive upgrade) * compelling documentation of use cases that feature 2.4; e.g., full deployment templates that include 2.4 as one part better ideas here On May 27, 2015, at 11:34 AM, William A Rowe Jr wr...@rowe-clan.net wrote: On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? Nope, we'll let the internet speak for itself - http://w3techs.com/technologies/history_details/ws-apache/2 We are nowhere near close enough to the inflection point of that graph to justify starting the 12 month EOL clock (which has been our traditional countdown, same as the Tomcat project). My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so That sounds about right. I'm personally interested in 3.0 - refactoring on trunk to clean up the evolution of httpd since 2.0.36. That was when we froze MMN majors, so many many bits are now shoehorned into the server in very awkward manners. This will make backports to 2.4 more complex, however. it would be nice to focus energy on 2.4 and later... Focus your energy on anything you like. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: 2.2 and 2.4 and 2.6/3.0
No need to go off... 2.2 has been out for almost 10 years. 2.4 for a bit over 3. That is a LONG time. I'm simply *suggesting* (no BDFL posturing Mr. Rowe) that after 10 years, maybe it's time to say that 2.2's era is done, and 2.4's time is here, if not already past. I'm simply trying to encourage us to work on the future and not focus on the past. No need to read anything more into that, or take on a onerous or holier-than-thou tone. My apologies if Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? was such an egregious question! Shame on me for even asking! :) On May 27, 2015, at 12:56 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Wed, May 27, 2015 at 11:33 AM, Jim Jagielski j...@jagunet.com wrote: Focus your energy on anything you like. Can't grok whether that's snarky or not... I'll assume not :) Please assume not :) ASF projects should still remain scratch-your-own-itch(es). Your message certainly had an 'adopt my agenda' tone to it, but I similarly didn't assume this was belligerent :) On Wed, May 27, 2015 at 11:32 AM, Jim Jagielski j...@jagunet.com wrote: My point is that if we EOL 2.2 (with some definition of EOL) then people on 2.2 (or earlier) will have some *real* incentive to move off of 2.2 towards 2.4 (or later)... Define people. The overwhelming majority of people use whatever is distributed with their OS. If your people are the distributors, just surveying current and immediately forthcoming distributions, it seems the message got through loud and clear. Basically, we need something to kick people off 2.2 and get them to 2.4. We've always used the 1 year yardstick, and from the graphs and distribution EOL's, 1 year is too soon. At the Tomcat project they generally support 3 major/minor releases in parallel. Here, our support has oscillated between 2 and 3 releases since 2.0.36. A new minor release has usually been the trigger to EOL the 3rd oldest release. In the real-world, we won't hit a point where there is only one major/minor release is wide use, not unless we slow the pace of major/minor releases to once every ten years ... not a goal to aspire to. By stating that 2.2 will ONLY get security related fixes and no new features or improvements, and that 2.2 will be EOL by 201X, that will be encouragement. It should be readily apparent from CHANGES for 2.2 and 2.4 which gets more attention. All of our announcements clarify that 2.4.new is the latest and greatest. If there are three PMC folks who want a bug fixed in 2.2, what is your point in establishing an agenda against that fix? In a BDFL project, that posturing is expected. Clearly there are very few bug fixes that attract developer's attention on 2.2 anymore. A better and perhaps less offensive question might be; how do we, as a project, communicate how legacy the legacy release really is? That, of course, assumes that we care one way or another about moving people to a more up-to-date and performant httpd, as well as whatever the future holds for httpd. Is there a reason you imply that contributors at this project don't seek this? The only divisions I see on the horizon are gaining consensus on the scope of any radical changes between 2.4.x and httpd-next.
Re: 2.2 and 2.4 and 2.6/3.0
Now that even stability-loving Debian is providing 2.4.x with full security support, moving on from 2.2 seems to make sense. -- Tim Bannister – is...@c8h10n4o2.org.uk
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 1:19 PM, Jim Jagielski j...@jagunet.com wrote: crazy and not-so-crazy ideas will speed the movement to 2.4 irrespective of distro schedules (not sure how much :) ) Here one: Since containers are the new hotness, how about being more Docker/Rocket/whatever friendly (whatever that means)? :) one thing it means is having compelling stories involving the latest hot tech that use 2.4 basically, any time there is a how-to-FOO somewhere on the www that uses nginx for the web server component, there needs to be a better how-to-FOO that uses httpd 2.4 ;) (I don't even think 2.2 is an issue here) Hope making this suggestion is OK and that OtherBill doesn't think I'm BDFL posturing! *duck* -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 11:33 AM, Jim Jagielski j...@jagunet.com wrote: Focus your energy on anything you like. Can't grok whether that's snarky or not... I'll assume not :) Please assume not :) ASF projects should still remain scratch-your-own-itch(es). Your message certainly had an 'adopt my agenda' tone to it, but I similarly didn't assume this was belligerent :) On Wed, May 27, 2015 at 11:32 AM, Jim Jagielski j...@jagunet.com wrote: My point is that if we EOL 2.2 (with some definition of EOL) then people on 2.2 (or earlier) will have some *real* incentive to move off of 2.2 towards 2.4 (or later)... Define people. The overwhelming majority of people use whatever is distributed with their OS. If your people are the distributors, just surveying current and immediately forthcoming distributions, it seems the message got through loud and clear. Basically, we need something to kick people off 2.2 and get them to 2.4. We've always used the 1 year yardstick, and from the graphs and distribution EOL's, 1 year is too soon. At the Tomcat project they generally support 3 major/minor releases in parallel. Here, our support has oscillated between 2 and 3 releases since 2.0.36. A new minor release has usually been the trigger to EOL the 3rd oldest release. In the real-world, we won't hit a point where there is only one major/minor release is wide use, not unless we slow the pace of major/minor releases to once every ten years ... not a goal to aspire to. By stating that 2.2 will ONLY get security related fixes and no new features or improvements, and that 2.2 will be EOL by 201X, that will be encouragement. It should be readily apparent from CHANGES for 2.2 and 2.4 which gets more attention. All of our announcements clarify that 2.4.new is the latest and greatest. If there are three PMC folks who want a bug fixed in 2.2, what is your point in establishing an agenda against that fix? In a BDFL project, that posturing is expected. Clearly there are very few bug fixes that attract developer's attention on 2.2 anymore. A better and perhaps less offensive question might be; how do we, as a project, communicate how legacy the legacy release really is? That, of course, assumes that we care one way or another about moving people to a more up-to-date and performant httpd, as well as whatever the future holds for httpd. Is there a reason you imply that contributors at this project don't seek this? The only divisions I see on the horizon are gaining consensus on the scope of any radical changes between 2.4.x and httpd-next.
Re: 2.2 and 2.4 and 2.6/3.0
crazy and not-so-crazy ideas will speed the movement to 2.4 irrespective of distro schedules (not sure how much :) ) Here one: Since containers are the new hotness, how about being more Docker/Rocket/whatever friendly (whatever that means)? :) Hope making this suggestion is OK and that OtherBill doesn't think I'm BDFL posturing! *duck*
Re: 2.2 and 2.4 and 2.6/3.0
On 27 May 2015, at 18:26, Jeff Trawick traw...@gmail.com wrote: one thing it means is having compelling stories involving the latest hot tech that use 2.4 basically, any time there is a how-to-FOO somewhere on the www that uses nginx for the web server component, there needs to be a better how-to-FOO that uses httpd 2.4 ;) (I don't even think 2.2 is an issue here) …same with forward- and reverse-proxying (Squid, Pound, Varnish, etc) Is the httpd wiki a good place to publish these? -- Tim Bannister – is...@c8h10n4o2.org.uk
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 4:11 PM, Tim Bannister is...@c8h10n4o2.org.uk wrote: On 27 May 2015, at 18:26, Jeff Trawick traw...@gmail.com wrote: one thing it means is having compelling stories involving the latest hot tech that use 2.4 basically, any time there is a how-to-FOO somewhere on the www that uses nginx for the web server component, there needs to be a better how-to-FOO that uses httpd 2.4 ;) (I don't even think 2.2 is an issue here) …same with forward- and reverse-proxying (Squid, Pound, Varnish, etc) Is the httpd wiki a good place to publish these? conceptually yes, but the performance is so bad that you'll probably give up -- Tim Bannister – is...@c8h10n4o2.org.uk -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: 2.2 and 2.4 and 2.6/3.0
Not wanting to boast, but maybe mod_h2 for httpd 2.4 can play a role in motivating people to migrate away from 2.2. I have not looked into having it work on 2.2 and no interest in doing so. If we get the ALPN support into 2.4.13, mod_h2 can be just dropped in to such a server. And distros will have an incentive to include it. In what amount that might influence 2.2 migrations, probably no one can foretell. And I have not the insight to what all others reasons for migration are, not knowing enough about the differences myself. I just want to point out that it can be one selling point among others. As to how to sell it: I have made some performance tests and published some numbers based on my single dev installation. It could certainly help to get some more numbers in a more real world like env to either have a story to tell - or find out what still needs to be done. What is floating around in the net are numbers from eithers servers no one can install (google) or servers that focus on http2 like h2o or nghttpd. But those are not general purpose servers, serve often only static files and sometimes even fail under load. I'm not saying they are bad implementations (far from it), there just not in the domain as httpd. cheers, Stefan Am 27.05.2015 um 19:26 schrieb Jeff Trawick traw...@gmail.com: one thing it means is having compelling stories involving the latest hot tech that use 2.4
Re: 2.2 and 2.4 and 2.6/3.0
Here at AL quite a lot sticking with 2.2 because third-party modules which are not available with 2.4. Like mod-perl etc. Op 27 mei 2015 om 22:42 heeft Stefan Eissing stefan.eiss...@greenbytes.de het volgende geschreven: Not wanting to boast, but maybe mod_h2 for httpd 2.4 can play a role in motivating people to migrate away from 2.2. I have not looked into having it work on 2.2 and no interest in doing so. If we get the ALPN support into 2.4.13, mod_h2 can be just dropped in to such a server. And distros will have an incentive to include it. In what amount that might influence 2.2 migrations, probably no one can foretell. And I have not the insight to what all others reasons for migration are, not knowing enough about the differences myself. I just want to point out that it can be one selling point among others. As to how to sell it: I have made some performance tests and published some numbers based on my single dev installation. It could certainly help to get some more numbers in a more real world like env to either have a story to tell - or find out what still needs to be done. What is floating around in the net are numbers from eithers servers no one can install (google) or servers that focus on http2 like h2o or nghttpd. But those are not general purpose servers, serve often only static files and sometimes even fail under load. I'm not saying they are bad implementations (far from it), there just not in the domain as httpd. cheers, Stefan Am 27.05.2015 um 19:26 schrieb Jeff Trawick traw...@gmail.com: one thing it means is having compelling stories involving the latest hot tech that use 2.4
Re: 2.2 and 2.4 and 2.6/3.0
On 2015-05-27 17:34, William A Rowe Jr wrote: On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski j...@jagunet.com wrote: Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? Nope, we'll let the internet speak for itself - http://w3techs.com/technologies/history_details/ws-apache/2 We are nowhere near close enough to the inflection point of that graph to justify starting the 12 month EOL clock (which has been our traditional countdown, same as the Tomcat project). My thoughts are that http/2 and mod_h2 will drive the trunk design efforts and so That sounds about right. I'm personally interested in 3.0 - refactoring on trunk to clean up the evolution of httpd since 2.0.36. That was when we froze MMN majors, so many many bits are now shoehorned into the server in very awkward manners. This will make backports to 2.4 more complex, however. it would be nice to focus energy on 2.4 and later... Focus your energy on anything you like. Not directly related to the EoL discussion, but some additional notices why a change to 2.4 takes some time. There where are some deal breakers for users to keep 2.2 running, most of them are fixed meanwhile. E.g. - mod_perl was for a long time not usable with 2.4, as a workaround most porters / packagers are shaping mod_perl for 2.4 directly from mod_perl trunk, now we see a first 2.0.9-rc1. - for long time there was no working mod_php module for 2.4, and changing to php-fpm was not for everyone a solution. - a bunch of third party modules are written for 2.0.x and do not build against 2.4, in some cases simply fixing s/r-useragent_ip/r-connection-remote_ip/ does the trick to make users happy I remember endless discussions removing apache 1.3 from the ports tree even one year after the 1.3 EoL, and the complain was not only from end users.
Re: 2.2 and 2.4 and 2.6/3.0
On 28/05/2015 07:38, olli hauer wrote: - for long time there was no working mod_php module for 2.4, and changing to php-fpm was not for everyone a solution. huh? I personally since dawn of the httpd/php love have always only ever used mod_php and at no time did I have a a non usable server with 2.4.x and mod_php, so I have NFI where you get this long time from, or any-time that I can see. I hope you just doubled up on your mod_perl, because that certainly was for a VERY long time not compatible with 2.4 (as you earlier mentioned).
Re: 2.2 and 2.4 and 2.6/3.0
On 28/05/2015 03:17, Jim Jagielski wrote: No need to go off... 2.2 has been out for almost 10 years. 2.4 for a bit over 3. That is a LONG time. I'm simply *suggesting* (no BDFL posturing Mr. Rowe) that after 10 years, maybe it's time to say that 2.2's era is done, and 2.4's time is here, if not already past. I'm simply trying to encourage us to work on the future and not focus on the past. No need to read anything more into that, or take on a onerous or holier-than-thou tone. My apologies if Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? was such an egregious question! Shame on me for even asking! :) From the responses I got when I mentioned EOL 2.2 in a discussion a few months back, it was very clear a few here enjoy living in the dark ages and were most passionate about staying there for the time being :) Cheers
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 6:59 PM, Noel Butler noel.but...@ausics.net wrote: On 28/05/2015 03:17, Jim Jagielski wrote: [...] maybe it's time to say that 2.2's era is done, and 2.4's time is here, if not already past. I'm simply trying to encourage us to work on the future and not focus on the past. No need to read anything more into that [...] My apologies if Anyone else think it's time to EOL 2.2 and focus on 2.4 and the next gen? was such an egregious question! Shame on me for even asking! :) From the responses I got when I mentioned EOL 2.2 in a discussion a few months back, it was very clear a few here enjoy living in the dark ages and were most passionate about staying there for the time being :) Or, a few here care about the users stuck in the situation of using the software in front of them, instead of dovetailing sideways against the current to build themselves a package that isn't in their distribution's repository. A few of us are very focused on the actual users using the actual software they were presented with. Hopefully, in a few years time, nobody will ever again be presented with 2.2, or 2.0, or 1.3. Given the most-common 3-year refresh cycle followed in our industry, that would mean about a year-and-a-half from now for SuSE users, and more than two years from now for the poor RHEL and CentOS users.
