On Dec 24, 2016 07:57, "Jim Jagielski" <j...@jagunet.com> wrote:
> On Dec 24, 2016, at 8:29 AM, Rich Bowen <rbo...@rcbowen.com> wrote: > > On 12/23/2016 03:52 PM, Jim Jagielski wrote: >> Personally, I don't think that backporting stuff to >> 2.4 prevents or disallows development on 2.6/3.0. In >> fact, I think it helps. We can easily do both... >> after all, we are still "working" on 2.2. >> >> As I have also stated, my personal belief is that >> 2.4 is finally reaching some traction, and if we >> "turn off" development/enhancement of 2.4, we will >> stop the uptake of 2.4 in its track. We need to keep >> 2.4 viable and worthwhile we, at the same time, work >> on 2.6/3.0. I think we all understand that getting >> 2.6/3.0 out will not be a quick and/or painless >> action. > > From my perspective, watching Nginx gain traction through superior > marketing, and channeling Dilbert's Pointy Haired Boss in assuming that > everything which I have never done must be simple, I, for one, would > like to see us release a 2.6, and more generally, to release a 2.x every > 2 years, or less, rather than every 4 years, or more. > > My opinion on this, I would emphasize, is 100% marketing, and 0% > technical. I realize we "don't do" marketing, but if we want to still ve > having the fun of doing this in another 20 years, it may be necessary to > get our name out there a little more frequently in terms of doing new > things. We are frankly not great at telling the world about the cool new > things we're doing. > Yeah, right now the way we are "doing marketing" is by continually adding features and enhancements to 2.4... It is what keeps 2.4 relevant and is what either keeps current httpd users using httpd or maybe help those on the fence decide on httpd instead of nginx/whatever. And again to play devil's advocate, how has that worked out in the four years of httpd 2.4? My point is that even having a 6 month minimal (and that is, IMO, widely optimistic and unrealistic) of "no new features for 2.4" means that we are basically giving people reasons to drop httpd. It would be a widely different story if (1) trunk was ready to release and (2) we "committed" to releasing trunk quickly by focusing on low-hanging fruit which would make lives happier and better for our end-users. As I said, my fear is that we will not be able to "control" ourselves in limiting what is in 2.6, which will push the actual release far past the point where it is even relevant. Well as breaking changes go, changing URI to remain an encoded value and to mandate module authors accept that req_rec is free threaded are breaking changes. We did that on conn_rec post-2.2. But I suspect that we have now done this to req_rec with the event mpm and sf's http2 enhancements already on 2.4? To be clear, if our goal was "Fork trunk as 2.5 NOW, polish and tune 2.5 'as-is' with minimal major refactoring with the goal of getting 2.6 out ASAP" then yeah, sure, the idea of "no new features in 2.4" would have some merit. But based on current conversation, it's obvious that, at least to me, that won't happen and we will be continually refactoring 2.6 to make it a 3.0. Two mistakes. If we commit to a new contract on these two things, there is never 2.6. Because fixing r->uri is such a priority, trust that I'll be voting every 2.6 candidate a -1 until it exists. I don't know why the original httpd founders are so hung up on version number conservation, they are cheap, but we are breaking a key field of a core request structure and no other OSS project would be stupid enough to call that n.m+1. So you can presume there is no such thing as 2.6. Error 2 and you ignored the first reply, there is no branch until 3.0 occurs. I'll save that detail for the next post. Again, you don't "stop" development on a current release until the next release is ready or, at least, "this close" to being ready. You don't sacrifice the present, nor do you leave your users in that limbo. Users had been in limbo 10 months for security fixes and far longer for bug fixes PatchAvailable in bugzilla, and you are worried about feature development on an maintenance branch. Sigh...
