Re: 2.6/3.0 yet again...
+1 This sounds like a good way forward. > Am 09.02.2018 um 14:10 schrieb Jim Jagielski : > > > >> On Feb 9, 2018, at 12:04 AM, William A Rowe Jr wrote: >> >> Since you won't permit 2.6/3.0 to come into existence, we can presume this >> was just a strawman? >> > > That is a false statement. If enough people wanted 2.6/3.0 to come > into existence, it would have. > > All I want is new functionality to be in our end-users hands > in a reasonable time-frame. The *only* way to do that is > via back porting to 2.4.x, due to the amount of time it > will take to release 2.6/3.0. During that time, httpd will further > lag behind, providing ammunition for further FUD and, IMO, > not serving our community well. > > I will make a commitment: as soon as we get 2.4.30 out, assuming > it has PROXY and uwsgi support, I will focus on helping get > 2.6/3.0 out on a fast-track schedule. My plan will be to > have a GM by sometime in May.
2.6/3.0 yet again...
> On Feb 9, 2018, at 12:04 AM, William A Rowe Jr wrote: > > Since you won't permit 2.6/3.0 to come into existence, we can presume this > was just a strawman? > That is a false statement. If enough people wanted 2.6/3.0 to come into existence, it would have. All I want is new functionality to be in our end-users hands in a reasonable time-frame. The *only* way to do that is via back porting to 2.4.x, due to the amount of time it will take to release 2.6/3.0. During that time, httpd will further lag behind, providing ammunition for further FUD and, IMO, not serving our community well. I will make a commitment: as soon as we get 2.4.30 out, assuming it has PROXY and uwsgi support, I will focus on helping get 2.6/3.0 out on a fast-track schedule. My plan will be to have a GM by sometime in May.
Re: 2.6/3.0
> On Dec 9, 2016, at 5:24 PM, William A Rowe Jr wrote: > > > Instead, maybe we could backport all that stuff to 2.4, in a backwards > compatible fashion. That is, basically backport trunk to 2.4. This > would give us more runway to work on httpd-nextgen. > > That is very unrealistic, given that the trunk patches have broken > ABI more than once a month for four years. Adapting such patches > would lead to many more inane forks like the HttpProtocol Strict > backport effort. > Well, instead of just throwing one's hands up and saying "That is very unrealistic" I am sure that there are some among us who instead are obstructionists, actually want to drive this project further along and would, as I explicitly state, try to figure out some way of doing so in a "backwards compatible fashion."
Re: 2.6/3.0
On Dec 9, 2016 21:56, "Daniel Ruggeri" wrote: On 12/9/2016 8:32 AM, Jim Jagielski wrote: > Instead, maybe we could backport all that stuff to 2.4, in a backwards > compatible fashion. That is, basically backport trunk to 2.4. This > would give us more runway to work on httpd-nextgen. > > Thoughts? Considering a lot of the changes in trunk, I'm not entirely sure it can be backported without creating some code maintenance challenges... I agree about the concern w/ branching so I guess it's really a matter of weighing the benefits - are there *enough* features to be worthy of a release, have we reached API stability to make it worth it and do we lose anything in our "sandbox" by doing this? Pressed for a response, I'd lean towards probably not but it's not a terribly strong opinion. It's also not unprecedented to have three major versions in play, too. It's been announced that 2.2 is on the "EOL" track with most folks interested in maintaining that branch in the 12 to 18 month range (June - Dec 2017ish). So, that said, it wouldn't be a super long time we maintain three branches... a year-ish from now. If that. Midyear is the 2.2 EOL. Patches for key security defects may be offered for a while longer, but no release votes. 3.0 isn't 'ready' but won't become ready unless we make an investment in alpha / beta releases and start breaking some eggs to move in that direction. Will it take 2 mos or 6 mos? Time will tell, but I would take the odds that we bless the next major GA release pretty close to the end of 2.2's lifespan, if we start now.
Re: 2.6/3.0
On 12/9/2016 8:32 AM, Jim Jagielski wrote: > Instead, maybe we could backport all that stuff to 2.4, in a backwards > compatible fashion. That is, basically backport trunk to 2.4. This > would give us more runway to work on httpd-nextgen. > > Thoughts? Considering a lot of the changes in trunk, I'm not entirely sure it can be backported without creating some code maintenance challenges... I agree about the concern w/ branching so I guess it's really a matter of weighing the benefits - are there *enough* features to be worthy of a release, have we reached API stability to make it worth it and do we lose anything in our "sandbox" by doing this? Pressed for a response, I'd lean towards probably not but it's not a terribly strong opinion. It's also not unprecedented to have three major versions in play, too. It's been announced that 2.2 is on the "EOL" track with most folks interested in maintaining that branch in the 12 to 18 month range (June - Dec 2017ish). So, that said, it wouldn't be a super long time we maintain three branches... a year-ish from now. -- Daniel Ruggeri
Re: 2.6/3.0
On Fri, Dec 9, 2016 at 8:32 AM, Jim Jagielski wrote: > It may be weird talking about httpd 2.6/3.0 when we are stuck > in a holding pattern for 2.4.24, but actually it's not a bad > idea. > > Right now, there are quite a few improvements in trunk that > should *really* be in a releasable version... Now we have some > options on how to proceed, but my modus operandi has been to > "push" as much trunk goodness back to 2.4 as possible, leaving > trunk still a nice sandbox for development on how we really want > to architecture the next gen (slave connections, etc...). So > as much as I think we should continue that, I also think it's > a disservice to keep the async, et.al. improvements in trunk, > well, in trunk. So we could fork 2.6 from trunk and work on > releasing 2.6. Assuming that we do so in a timely fashion, that > would mean we would have 3 versions out: 2.2, 2.4, and 2.6. > Considering that 2.4 is finally showing some traction, I wonder > if that's the right move. > Well, that isn't how we work, we don't fork 2.6 before 2.5.whatnot. We release 2.5.0-alpha (or -beta). Unless you want to redesign the process and open that hard-won consensus all over again. Then another -alpha/-beta, and so on, until we have consensus to tag trunk as the 2.6.0/3.0.0 release. Then we take a deep breath and fork 2.6.x/3.0.x branch from trunk. This keeps 2.5 as close to the bleeding edge as possible during the next release process, with major API changes and broken binary compatibility between the individual alpha/beta samples, so that others in our ecosystem may adapt their modules throughout the process, and are (one hopes) ready for the 2.6.0/3.0.0 release. You and I (and others, I suspect) agree there is a lot of trunk goodness to release soon. Other things that would likely happen during the 2.5.x phases are a reworking/restructuring of utility vs server facilities (something which is a complete mess at this moment), collapsing _ex() functions into their historic function names, etc. Restoring the ability to load modules out of order after the chaos of poorly thought out new 'hub-and-spoke' modules. And there are other discussions afoot around the PMC about major API changes that will break some developer assumptions, and I believe will cause us to take this to 3.0.0, not some minor revision bump. > Instead, maybe we could backport all that stuff to 2.4, in a backwards > compatible fashion. That is, basically backport trunk to 2.4. This > would give us more runway to work on httpd-nextgen. > That is very unrealistic, given that the trunk patches have broken ABI more than once a month for four years. Adapting such patches would lead to many more inane forks like the HttpProtocol Strict backport effort. The other 'instead' is that we could throw away trunk, and branch a new trunk from 2.4.x branch, if we are not comfortable releasing the contents of trunk as an alpha or beta release. I hope that's not the case.
2.6/3.0
It may be weird talking about httpd 2.6/3.0 when we are stuck in a holding pattern for 2.4.24, but actually it's not a bad idea. Right now, there are quite a few improvements in trunk that should *really* be in a releasable version... Now we have some options on how to proceed, but my modus operandi has been to "push" as much trunk goodness back to 2.4 as possible, leaving trunk still a nice sandbox for development on how we really want to architecture the next gen (slave connections, etc...). So as much as I think we should continue that, I also think it's a disservice to keep the async, et.al. improvements in trunk, well, in trunk. So we could fork 2.6 from trunk and work on releasing 2.6. Assuming that we do so in a timely fashion, that would mean we would have 3 versions out: 2.2, 2.4, and 2.6. Considering that 2.4 is finally showing some traction, I wonder if that's the right move. Instead, maybe we could backport all that stuff to 2.4, in a backwards compatible fashion. That is, basically backport trunk to 2.4. This would give us more runway to work on httpd-nextgen. Thoughts?
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 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: 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
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 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 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 27 May 2015, at 13:54, Jim Jagielski 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
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 05/28/2015 03:54 PM, Jim Riggs wrote: On 28 May 2015, at 14:30, Reindl Harald 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 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
On Thu, May 28, 2015 at 3:45 PM, William A Rowe Jr wrote: > On May 27, 2015 9:46 AM, "Jeff Trawick" wrote: > > > > On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick > wrote: > >> > >> On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski 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 28 May 2015, at 14:30, Reindl Harald 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 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" wrote: > > On Wed, May 27, 2015 at 10:42 AM, Jeff Trawick wrote: >> >> On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski 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
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%2Edev&page=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 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 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
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
> > 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
please dont sent other mail Arash.S 📧 Sent from📱 〰〰 On May 28, 2015, at 3:46 PM, Jim Jagielski 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 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 time&effort) 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 wrote: > > On 28 May 2015, at 4:46 PM, Jim Jagielski 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
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 : > > 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 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 time&effort) where my mouth is! >> >> -- >> Nick Kew >> > 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
On 28 May 2015, at 4:46 PM, Jim Jagielski 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
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 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 time&effort) where my mouth is! > > -- > Nick Kew >
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 time&effort) where my mouth is! -- Nick Kew
Re: 2.2 and 2.4 and 2.6/3.0
On Wed, May 27, 2015 at 1:41 PM, William A Rowe Jr 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, May 27, 2015 at 6:59 PM, Noel Butler 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.
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 2015-05-27 17:34, William A Rowe Jr wrote: > On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski 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
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 > 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 : >> >> 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
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 : > > 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 Wed, May 27, 2015 at 4:11 PM, Tim Bannister wrote: > On 27 May 2015, at 18:26, Jeff Trawick 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
On 27 May 2015, at 18:26, Jeff Trawick 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
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
> > 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
On Wed, May 27, 2015 at 12:17 PM, Jim Jagielski 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. wrote: > On Fri, 13 Mar 2015 08:28:35 +1000 > Noel Butler 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
On Wed, May 27, 2015 at 1:19 PM, Jim Jagielski 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
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
> > 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
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 wrote: > > On Wed, May 27, 2015 at 11:33 AM, Jim Jagielski 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 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
On Wed, May 27, 2015 at 12:32 PM, Jim Jagielski 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 <> > > > On May 27, 2015, at 11:34 AM, William A Rowe Jr > wrote: > > > > On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski 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
On Wed, May 27, 2015 at 11:33 AM, Jim Jagielski 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 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
> > 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
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 wrote: > > On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski 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
> > 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
On Wed, May 27, 2015 at 7:54 AM, Jim Jagielski 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 wrote: > On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski 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 wrote: > On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski 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
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 10:42 AM, Jeff Trawick wrote: > On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski 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
On Wed, May 27, 2015 at 8:54 AM, Jim Jagielski 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
On Wed, May 27, 2015 at 8:55 AM Jim Jagielski 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 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...
2.2 and 2.4 and 2.6/3.0
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...
