Post 2.4.25

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Post 2.4.25

Jim Jagielski
Now that we have 2.4.25 done, I'd like us to take the
next few weeks thinking about how we'd like to see
the next release shape up.

For me, it would be moving as much as we can from
trunk to 2.4, again, to enable current users to
leverage and enjoy the goodness which is currently
"stuck" in trunk. Some can be backported, some can't
of course, but it seems wise to try to backport what
we can. Other stuff, like brotli, seem low-hanging-fruit
which is ready to be plucked.

We should also, now that 2.4.25 is out with fixes/work-
arounds for some issues, tighten them up as needed.

No rush, of course, but assuming that many of us
have the next week or so as some "time off", it
might be a good opportunity for us to spend some of
our own time thinking what's next.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

William A Rowe Jr
On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski <[hidden email]> wrote:
For me, it would be moving as much as we can from
trunk to 2.4

-1. To echo your frequent use of media to emphasize
the point, with a song nearly as old as us;

Next step is to actually end enhancements alltogether
against 2.4 (we've done that some time ago, security
issues notwithstanding, on 2.2), and push all of the
enhancement effort towards 3.0 (2.5-dev). Of course,
we should continue to pick up bug fixes and help those
still on 2.4 have a good day.

Let those users looking for cool new things pick up
the 3.0 release.

Or else you are kicking 'everything we can't' further
down the road, again dismissing all of the activity 
of so many of our fellow committers. Stale stuff on
trunk/ now dates to over 4 years ago.

That state of things simply sucks.

Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Jim Jagielski
Personally, I don't think that backporting stuff to
2.4 prevents or disallows development on 2.6/3.0. In
fact, I think it helps. We can easily do both...
after all, we are still "working" on 2.2.

As I have also stated, my personal belief is that
2.4 is finally reaching some traction, and if we
"turn off" development/enhancement of 2.4, we will
stop the uptake of 2.4 in its track. We need to keep
2.4 viable and worthwhile we, at the same time, work
on 2.6/3.0. I think we all understand that getting
2.6/3.0 out will not be a quick and/or painless
action.

Maybe the whole thing revolves around us mistakenly
using the term "2.6/3.0"... I seen trunk as something
that could become 2.6 in "short order", if that's
the direction we want to go. But there is also the
need and desire to really clean-up the codebase (r->uri
is the common example used), which means a codebase
which is more 3.0 related, and therefore, more extensive
and thus taking more time.

However, by us using the term "2.6/3.0" it muddies
the water, and implies that 2.6 could be much
more pervasive that it already is.

The long and short is that there is good stuff in trunk.
It should be available to our users sooner rather than
later. If you want to call that 2.6, fine. What I don't
want to see, since I don't think it is a viable solution,
is for us to say "OK, let's tag trunk as 2.5 with the goal
of getting 2.6 out soon... But hold on, this is broken and
we need to completely refactor this. And this is weird, let's
strip this out and replace it with this... And while we
are at it, let's change this to do that" with the end
result that 2.5/2.6 takes ages and 2.4 is left fallow. And,
to be honest, I think that is exactly what will happen.
The turd will never be polished enuff.

And our community suffers.

So, to make it crystal clear, I am 100% FOR httpd-next-gen.
All I am saying is that we have an existing user base
which is still mostly on 2.2, much less 2.4, and they
are currently at a disadvantage by not having access
to the latest and greatest stuff which is locked away
in trunk and could be available for them, *while httpd-next-gen
is being worked in parallel*.

Nothing is preventing people from playing on trunk... But my
feeling is that most people like hacking code that people
eventual run in short order and in a timely timeframe. Waiting
6-12-18 months for "new features" is how commercial s/w works,
not FOSS.

  https://w3techs.com/technologies/details/ws-apache/2/all


I will ignore the likelihood that httpd-next-gen will require
APR 2.0 which may also take a long time to be released.

> On Dec 23, 2016, at 3:28 PM, William A Rowe Jr <[hidden email]> wrote:
>
> On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski <[hidden email]> wrote:
> For me, it would be moving as much as we can from
> trunk to 2.4
>
> -1. To echo your frequent use of media to emphasize
> the point, with a song nearly as old as us;
> https://www.youtube.com/watch?v=EsCyC1dZiN8
>
> Next step is to actually end enhancements alltogether
> against 2.4 (we've done that some time ago, security
> issues notwithstanding, on 2.2), and push all of the
> enhancement effort towards 3.0 (2.5-dev). Of course,
> we should continue to pick up bug fixes and help those
> still on 2.4 have a good day.
>
> Let those users looking for cool new things pick up
> the 3.0 release.
>
> Or else you are kicking 'everything we can't' further
> down the road, again dismissing all of the activity
> of so many of our fellow committers. Stale stuff on
> trunk/ now dates to over 4 years ago.
>
> That state of things simply sucks.
>

Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

William A Rowe Jr
Just a couple quick thoughts...

On Dec 23, 2016 2:55 PM, "Jim Jagielski" <[hidden email]> wrote:

As I have also stated, my personal belief is that
2.4 is finally reaching some traction, and if we
"turn off" development/enhancement of 2.4, we will
stop the uptake of 2.4 in its track.

I think you might be misconstruing our flaws in httpd with our version numbering scheme. 

There is only one other project with our longevity that refuses to bump version majors, and they are suddenly 2 versions ahead of us in only a few short years. If you haven't guessed, that's the Linux Kernel.


. We need to keep
2.4 viable and worthwhile

So long as we fix the bugs, it is.

Maybe the whole thing revolves around us mistakenly
using the term "2.6/3.0"...

I ceased doing this. After another admonishment that version numbers are cheap, and out team's concensus that treating r->uri as a decoded value was a wrong call, we won't have a release that can be called 2.next.

During its incubation of alphas and betas, it still remains 2.5.x, but on completion I can't imagine calling this 2.6. This will be a fundamental change that requires a 3.0 designation.

I don't see us taking shortcuts to get to that point, but believe it is a change that will occur in a very short timespan, because several committers want to see this happen.

So long as it is foretold that nobody is blocking 3.0, unlike 3 years ago, I expect that sort of energy and enthusiasm to take hold toward a GA release in the next six months, if we don't get bogged down in more backport type of activity.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Jim Jagielski-2
Well, since I am actively working on trunk, I am obviously interested in seeing continued work being done on it and the work being usable to our users in a timely fashion. Since backports to 2.2 have not affected work on 2.4 or trunk, it is obvious as well that any backport efforts for 2.4 won't be any issue at all, so work on trunk will be unrestricted. I hope your enthusiasm regarding timeframes is warranted and accurate. Obviously my efforts are directed towards what is best for our community and am looking forward to how we continue with next gen.

On 2016-12-23 17:50 (-0500), William A Rowe Jr <[hidden email]> wrote:

> Just a couple quick thoughts...
>
> On Dec 23, 2016 2:55 PM, "Jim Jagielski" <[hidden email]> wrote:
>
>
> As I have also stated, my personal belief is that
> 2.4 is finally reaching some traction, and if we
> "turn off" development/enhancement of 2.4, we will
> stop the uptake of 2.4 in its track.
>
>
> I think you might be misconstruing our flaws in httpd with our version
> numbering scheme.
>
> There is only one other project with our longevity that refuses to bump
> version majors, and they are suddenly 2 versions ahead of us in only a few
> short years. If you haven't guessed, that's the Linux Kernel.
>
>
> . We need to keep
> 2.4 viable and worthwhile
>
>
> So long as we fix the bugs, it is.
>
> Maybe the whole thing revolves around us mistakenly
> using the term "2.6/3.0"...
>
>
> I ceased doing this. After another admonishment that version numbers are
> cheap, and out team's concensus that treating r->uri as a decoded value was
> a wrong call, we won't have a release that can be called 2.next.
>
> During its incubation of alphas and betas, it still remains 2.5.x, but on
> completion I can't imagine calling this 2.6. This will be a fundamental
> change that requires a 3.0 designation.
>
> I don't see us taking shortcuts to get to that point, but believe it is a
> change that will occur in a very short timespan, because several committers
> want to see this happen.
>
> So long as it is foretold that nobody is blocking 3.0, unlike 3 years ago,
> I expect that sort of energy and enthusiasm to take hold toward a GA
> release in the next six months, if we don't get bogged down in more
> backport type of activity.
>
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Jim Jagielski
In reply to this post by William A Rowe Jr

> On Dec 23, 2016, at 5:50 PM, William A Rowe Jr <[hidden email]> wrote:
>
> Just a couple quick thoughts...
>
> On Dec 23, 2016 2:55 PM, "Jim Jagielski" <[hidden email]> wrote:
>
> . We need to keep
> 2.4 viable and worthwhile
>
> So long as we fix the bugs, it is.
>

Personally, especially considering the current landscape, I
believe that statement is simply wrong. Saying "just bug fixes"
for 2.4 for some unknown number of months is just flat out
incorrect when we haven't even EOLed it and, in fact, when
2.2 is still available, supported and would be in that self-
same mode.

"actually end enhancements alltogether against 2.4" at this
point is a sure fire way to completely kill Apache httpd and
is not required in the least. You seem to forget that people
can, and want, to do both. We do not, and should not, control
and restrict, without very good, solid, reasons, what people
do on their own free time here.

Just as it is "unwise" or "authoritarian" to "block" work
on trunk, it is the same for 2.4, considering the situation
that we are in *right now*. We need to continue to be relevant
and innovative in 2.4 while we are, at the same time, creating
the next rev. Suffocating one before its "replacement" is
even in pre-alpha stage is simply not needed nor is it a
wise move project-management-wise. It is unfair to our users.

It's like saying you can't have another kid until your youngest
is 18 :)

Cheers.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

William A Rowe Jr
In reply to this post by Jim Jagielski-2
On Dec 23, 2016 9:58 PM, "Jim Jagielski" <[hidden email]> wrote:
Well, since I am actively working on trunk, I am obviously interested in seeing continued work being done on it and the work being usable to our users in a timely fashion. Since backports to 2.2 have not affected work on 2.4 or trunk, it is obvious as well that any backport efforts for 2.4 won't be any issue at all, so work on trunk will be unrestricted.

Restrictions, no, never. But if I had to ask how did that work out for me merging antique commits back at 2.4 and from 2.4 to 2.2, you don't want my opinion on your therom.

I hope your enthusiasm regarding timeframes is warranted and accurate. Obviously my efforts are directed towards what is best for our community and am looking forward to how we continue with next gen.

As do I.

Different refutation of your underlying therom on versioning will happen on or after the weekend. In the meantime...

A joyous belated Solstice, happy Hanukkah, merry Christmas, or just wishing everyone a good weekend. You have all been some of.my most favorite people now for 15+ years.  See you all next year :)
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Rich Bowen
In reply to this post by Jim Jagielski


On 12/23/2016 03:52 PM, Jim Jagielski wrote:

> Personally, I don't think that backporting stuff to
> 2.4 prevents or disallows development on 2.6/3.0. In
> fact, I think it helps. We can easily do both...
> after all, we are still "working" on 2.2.
>
> As I have also stated, my personal belief is that
> 2.4 is finally reaching some traction, and if we
> "turn off" development/enhancement of 2.4, we will
> stop the uptake of 2.4 in its track. We need to keep
> 2.4 viable and worthwhile we, at the same time, work
> on 2.6/3.0. I think we all understand that getting
> 2.6/3.0 out will not be a quick and/or painless
> action.
From my perspective, watching Nginx gain traction through superior
marketing, and channeling Dilbert's Pointy Haired Boss in assuming that
everything which I have never done must be simple, I, for one, would
like to see us release a 2.6, and more generally, to release a 2.x every
2 years, or less, rather than every 4 years, or more.

My opinion on this, I would emphasize, is 100% marketing, and 0%
technical. I realize we "don't do" marketing, but if we want to still ve
having the fun of doing this in another 20 years, it may be necessary to
get our name out there a little more frequently in terms of doing new
things. We are frankly not great at telling the world about the cool new
things we're doing.


--
Rich Bowen - [hidden email] - @rbowen
http://apachecon.com/ - @apachecon


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Eric Covener
In reply to this post by William A Rowe Jr
On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr <[hidden email]> wrote:
> Next step is to actually end enhancements alltogether
> against 2.4 (we've done that some time ago, security
> issues notwithstanding, on 2.2), and push all of the
> enhancement effort towards 3.0 (2.5-dev). Of course,
> we should continue to pick up bug fixes and help those
> still on 2.4 have a good day.
>
> Let those users looking for cool new things pick up
> the 3.0 release.

What's the carrot for users/developers in a 2.6/3.0? I'm not sure
they'd come along for this ride.  To play devils advocate, it seems
like many of the breaking changes could be imposed by having
deprecated fields/accessors (maybe moving to more of the latter) and
preferred alternatives (to avoid major MMN bumps).

Anyone with ideas about what they'd want in a new release is
encouraged to add them to the trunk STATUS file, even if they are just
wishlist items -- it's not a commitment.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Jim Jagielski
In reply to this post by Rich Bowen

> On Dec 24, 2016, at 8:29 AM, Rich Bowen <[hidden email]> wrote:
>
>
>
> On 12/23/2016 03:52 PM, Jim Jagielski wrote:
>> Personally, I don't think that backporting stuff to
>> 2.4 prevents or disallows development on 2.6/3.0. In
>> fact, I think it helps. We can easily do both...
>> after all, we are still "working" on 2.2.
>>
>> As I have also stated, my personal belief is that
>> 2.4 is finally reaching some traction, and if we
>> "turn off" development/enhancement of 2.4, we will
>> stop the uptake of 2.4 in its track. We need to keep
>> 2.4 viable and worthwhile we, at the same time, work
>> on 2.6/3.0. I think we all understand that getting
>> 2.6/3.0 out will not be a quick and/or painless
>> action.
>
> From my perspective, watching Nginx gain traction through superior
> marketing, and channeling Dilbert's Pointy Haired Boss in assuming that
> everything which I have never done must be simple, I, for one, would
> like to see us release a 2.6, and more generally, to release a 2.x every
> 2 years, or less, rather than every 4 years, or more.
>
> My opinion on this, I would emphasize, is 100% marketing, and 0%
> technical. I realize we "don't do" marketing, but if we want to still ve
> having the fun of doing this in another 20 years, it may be necessary to
> get our name out there a little more frequently in terms of doing new
> things. We are frankly not great at telling the world about the cool new
> things we're doing.
>

Yeah, right now the way we are "doing marketing" is by
continually adding features and enhancements to 2.4... It
is what keeps 2.4 relevant and is what either keeps current
httpd users using httpd or maybe help those on the fence decide
on httpd instead of nginx/whatever.

My point is that even having a 6 month minimal (and that
is, IMO, widely optimistic and unrealistic) of "no new
features for 2.4" means that we are basically giving people
reasons to drop httpd. It would be a widely different story
if (1) trunk was ready to release and (2) we "committed" to
releasing trunk quickly by focusing on low-hanging fruit
which would make lives happier and better for our end-users.
As I said, my fear is that we will not be able to "control"
ourselves in limiting what is in 2.6, which will push the
actual release far past the point where it is even relevant.

To be clear, if our goal was "Fork trunk as 2.5 NOW, polish
and tune 2.5 'as-is' with minimal major refactoring with
the goal of getting 2.6 out ASAP" then yeah, sure, the idea
of "no new features in 2.4" would have some merit. But based
on current conversation, it's obvious that, at least to me,
that won't happen and we will be continually refactoring 2.6
to make it a 3.0. Again, you don't "stop" development on a
current release until the next release is ready or, at least,
"this close" to being ready. You don't sacrifice the present,
nor do you leave your users in that limbo.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Jim Jagielski
In reply to this post by Eric Covener

> On Dec 24, 2016, at 8:54 AM, Eric Covener <[hidden email]> wrote:
>
> On Fri, Dec 23, 2016 at 3:28 PM, William A Rowe Jr <[hidden email]> wrote:
>> Next step is to actually end enhancements alltogether
>> against 2.4 (we've done that some time ago, security
>> issues notwithstanding, on 2.2), and push all of the
>> enhancement effort towards 3.0 (2.5-dev). Of course,
>> we should continue to pick up bug fixes and help those
>> still on 2.4 have a good day.
>>
>> Let those users looking for cool new things pick up
>> the 3.0 release.
>
> What's the carrot for users/developers in a 2.6/3.0? I'm not sure
> they'd come along for this ride.  To play devils advocate, it seems
> like many of the breaking changes could be imposed by having
> deprecated fields/accessors (maybe moving to more of the latter) and
> preferred alternatives (to avoid major MMN bumps).
>

Yeah, that is kind of alluded to in my thoughts. For 3.0 to
*really* be a major carrot, we are talking (IMO), a major
refactoring. A super streamlining of filters, etc. I used
to think making use of Serf would be it, but instead I'm
thinking libmill/libdill would be better (plus, to be honest,
I still can't figure out all the ins and outs of Serf and
there's no documentation at all)...

In other words, to ensure that people come along for the
ride, the ride has to be revolutionary, at least at some
level. And that, imo, takes time to architecture, design,
implement and test. If we say "no new stuff for 2.4 until
then" then, as I have stated, we have given all our current
users a great reason and rationale for leaving, and they
will.

I'm not saying we don't do one so we can do the other; I'm
saying we do both, at the same time, in parallel. I still
don't understand why that concept is such an anathema to some
people.

> Anyone with ideas about what they'd want in a new release is
> encouraged to add them to the trunk STATUS file, even if they are just
> wishlist items -- it's not a commitment.

Added some of mine already :)

Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Rich Bowen
In reply to this post by Jim Jagielski


On Dec 24, 2016 10:57, "Jim Jagielski" <[hidden email]> wrote:


Yeah, right now the way we are "doing marketing" is by
continually adding features and enhancements to 2.4... It
is what keeps 2.4 relevant and is what either keeps current
httpd users using httpd or maybe help those on the fence decide
on httpd instead of nginx/whatever.

My point is that even having a 6 month minimal (and that
is, IMO, widely optimistic and unrealistic) of "no new
features for 2.4" means that we are basically giving people
reasons to drop httpd.

Oh, sure, I agree with that. Six months of (perceived) inaction would tell the world we're all done. I'm probably answering a different question.  :)

Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Eric Covener
In reply to this post by Jim Jagielski
> I'm not saying we don't do one so we can do the other; I'm
> saying we do both, at the same time, in parallel. I still
> don't understand why that concept is such an anathema to some
> people.

I also worry about our ability to deliver a 3.0 with enough
re-architecture for us and and function for users, vs a more
continuous delivery (apologies for bringing buzzaords to dev@httpd)
cadence on 2.4 as we've been in.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Mark Blackman

> On 24 Dec 2016, at 16:32, Eric Covener <[hidden email]> wrote:
>
>> I'm not saying we don't do one so we can do the other; I'm
>> saying we do both, at the same time, in parallel. I still
>> don't understand why that concept is such an anathema to some
>> people.
>
> I also worry about our ability to deliver a 3.0 with enough
> re-architecture for us and and function for users, vs a more
> continuous delivery (apologies for bringing buzzaords to dev@httpd)
> cadence on 2.4 as we've been in.

If you can find a way with limited resources, I would encourage doing both in parallel as well.

What are the 2.6/3.0 re-architecture goals/vision out of curiosity?

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

William A Rowe Jr
In reply to this post by Jim Jagielski
On Dec 24, 2016 07:57, "Jim Jagielski" <[hidden email]> wrote:

> On Dec 24, 2016, at 8:29 AM, Rich Bowen <[hidden email]> 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...
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

William A Rowe Jr
In reply to this post by Eric Covener
On Dec 24, 2016 08:32, "Eric Covener" <[hidden email]> wrote:
> I'm not saying we don't do one so we can do the other; I'm
> saying we do both, at the same time, in parallel. I still
> don't understand why that concept is such an anathema to some
> people.

I also worry about our ability to deliver a 3.0 with enough
re-architecture for us and and function for users, vs a more
continuous delivery (apologies for bringing buzzaords to dev@httpd)
cadence on 2.4 as we've been in.

Here is the confusion (see the versioning thread.)

2.6 is a break in ABI compatibility.

3.0 is a break in API compatibility.

Size in this case doesn't matter. Any break at all merits these changes.

We are not a commercial product. We are httpd. Nobody cares what the version no is other than us, they very largely install and forget, OS vendors grab new at one point in their distribution gathering phase and don't revisit.

Adoption outside of OS distros is largely irrelevant. Talk about do-nothing, PCRE2 has been out a very long time with all the activity and no adoption, PCRE 8.x is on life support with little pulse and is the defacto standard.

Your assumptions don't reflect the actual adoption behaviors.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Yann Ylavic
In reply to this post by William A Rowe Jr
[Bill, you definitely should do something with your email client, e.g.
using plain text only, replying to your messages breaks indentation
level (like the number of '>' preceding/according to the initial
message)].

On Thu, Dec 29, 2016 at 12:28 AM, William A Rowe Jr <[hidden email]> wrote:
>
> On Dec 24, 2016 07:57, "Jim Jagielski" <[hidden email]> wrote:
>
[For example, here I had to add a '>' for Jim's original text to be
associated with the above "Jim ... wrote:"]

>>
>> My point is that even having a 6 month minimal (and that
>> is, IMO, widely optimistic and unrealistic) of "no new
>> features for 2.4" means that we are basically giving people
>> reasons to drop httpd. It would be a widely different story
>> if (1) trunk was ready to release and (2) we "committed" to
>> releasing trunk quickly by focusing on low-hanging fruit
>> which would make lives happier and better for our end-users.
>> As I said, my fear is that we will not be able to "control"
>> ourselves in limiting what is in 2.6, which will push the
>> actual release far past the point where it is even relevant.
>
> Well as breaking changes go, changing URI to remain an encoded value and to
> mandate module authors accept that req_rec is free threaded are breaking
> changes.

Not sure what the second point means, but preserving r->uri while also
allowing to (and internally work with) an escaped form of the URI does
not necessarily require an API change.
(We could possibly have an opaque struct to manipulate the URI in its
different forms and some helper(s) be compatible with the API changes'
requirements, e.g. 2.4.x).

Regarding the changes in configuration/behaviours, I don't think we
should break things anyway (even accross majors, if possible/relevant
of course), but rather provide options to have the one or the other
behaviour (trunk having the now considered better behaviour, stable(s)
the compatible one).

My point is mainly that rather than focusing on version numbers, we
probably should focus on:
1. what we have now (in trunk), and want to backport
2. what we don't have now, do it (the better wrt trunk), and go to 1.

There's (almost) always a way to backport things, though it should not
prevent us from doing the *necessary* changes (in trunk) for new
improvements/features.

Yet, first step is the "inventory" of what we have/want, each/all of
us involved and constructive...

Once this is done, let's see what is compatible or not (and if yes at
which cost).
If we are going to introduce incompatible features, let's do 3.x.
If we are going to introduce many features at once, let's do 2.6.x
(that's an announce/marketing "value", the user does not care about
the version, (s)he does about the features).
Otherwise let's continue improving trunk with 2.4.x.

When we start implementing new features, first discuss/specify them,
then implement, and see if it's compatible/backportable.
For now, I don't see many (if any) incompatibilities in trunk (I
surely don't have an exhaustive view), but many improvements to
backport.

Just my 2 cts...

Regards,
Yann.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Jim Jagielski
In reply to this post by William A Rowe Jr

> On Dec 28, 2016, at 6:28 PM, William A Rowe Jr <[hidden email]> wrote:
>
>
> Because fixing r->uri is such a priority, trust that I'll be voting every 2.6 candidate a -1 until it exists. I don't know why the original httpd founders are so hung up on version number conservation, they are cheap, but we are breaking a key field of a core request structure and no other OSS project would be stupid enough to call that n.m+1.
>

Who is digging in their heels and blocking new development
now?

So you are admitting that you will "veto" (although you
can't veto a release) any 2.5.* "releases" unless and
until r->uri is "fixed". Which implies, obviously, a
very substantial refactoring. Which implies time. Which
implies that if you also say "no new enhancements in 2.4"
that it will be a long time until anything new and useful
will be added to, or available to, our end-users until
some unknown future time.

And that is acceptable to you?

And no one I know of in any way is "hung up on version
number conservation", and that is moot and strawman anyway.

As fair warning, I fully expect that we will release 2.4.26
within the next 3 months. I also fully expect that some
"new enhancements" from trunk to be backported and be in
that release.

I simply care about continuing to keep Apache httpd relevant
and a continued viable offering for our community. That
means us working on next-gen, of course, but also maintaining
and fostering a community until next-gen exists.
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

William A Rowe Jr
On Thu, Dec 29, 2016 at 8:23 AM, Jim Jagielski <[hidden email]> wrote:

>
>> On Dec 28, 2016, at 6:28 PM, William A Rowe Jr <[hidden email]> wrote:
>>
>> Because fixing r->uri is such a priority, trust that I'll be voting every 2.6 candidate a -1 until it exists. I don't know why the original httpd founders are so hung up on version number conservation, they are cheap, but we are breaking a key field of a core request structure and no other OSS project would be stupid enough to call that n.m+1.
>
> Who is digging in their heels and blocking new development
> now?
>
> So you are admitting that you will "veto" (although you
> can't veto a release) any 2.5.* "releases" unless and
> until r->uri is "fixed".

Wow, Jim, how did you misread my assertion that I'd oppose 2.6 GA
or 3.0 GA release until feature "X", where "X" represents the heavy-lift
of not using filesystem syntax as the uri path except for files, honoring
the URI and HTTP RFC, and therefore requiring some module authors to
re-think how they consumed or changed/assigned r->uri. Modules such
as proxy would actually pass on the *presented* uri (if valid) to the back
end http server - just imagine that. That change I'm expecting we all
want to call out as 3.0 for our developers, even though there are no
directives changed for our users so administration doesn't change.

How did you jump to the conclusion that I'd block an -alpha or -beta
release on the 2.5.x trunk? Usually takes some number of incremental
-alpha/-beta tags to get to GA.

And how did you translate 'vote -1' to veto?
Reply | Threaded
Open this post in threaded view
|

Re: Post 2.4.25

Stefan Fritsch
In reply to this post by Rich Bowen
On Saturday, 24 December 2016 08:29:35 CET Rich Bowen wrote:
> From my perspective, watching Nginx gain traction through superior
> marketing, and channeling Dilbert's Pointy Haired Boss in assuming that
> everything which I have never done must be simple, I, for one, would
> like to see us release a 2.6, and more generally, to release a 2.x every
> 2 years, or less, rather than every 4 years, or more.

There is the problem that on the one hand, one should do some invasive changes
in trunk to improve the architecture. On the other hand, this is problematic
if the 2.6/3.0 release is not coming soon because

* it makes it difficult to backport stuff to 2.4.x

* there is the danger that the people who did the invasive changes are no
longer around when 2.6/3.0 is actually release. We had this problem with the
authn/authz stuff for 2.4, which took quite some time to get fixed.

* the longer 2.6/3.0 takes the more half-baked/half-finished stuff accumulates
that needs to be fixed before a release.

But I don't have any ideas how to resolve this.

Cheers,
Stefan

12