Re: Post 2.4.25
On Dec 23, 2016 9:58 PM, "Jim Jagielski" wrote: Well, since I am actively working on trunk, I am obviously interested in seeing continued work being done on it and the work being usable to our users in a timely fashion. Since backports to 2.2 have not affected work on 2.4 or trunk, it is obvious as well that any backport efforts for 2.4 won't be any issue at all, so work on trunk will be unrestricted. Restrictions, no, never. But if I had to ask how did that work out for me merging antique commits back at 2.4 and from 2.4 to 2.2, you don't want my opinion on your therom. I hope your enthusiasm regarding timeframes is warranted and accurate. Obviously my efforts are directed towards what is best for our community and am looking forward to how we continue with next gen. As do I. Different refutation of your underlying therom on versioning will happen on or after the weekend. In the meantime... A joyous belated Solstice, happy Hanukkah, merry Christmas, or just wishing everyone a good weekend. You have all been some of.my most favorite people now for 15+ years. See you all next year :)
Re: Post 2.4.25
> On Dec 23, 2016, at 5:50 PM, William A Rowe Jr wrote: > > Just a couple quick thoughts... > > On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote: > > . We need to keep > 2.4 viable and worthwhile > > So long as we fix the bugs, it is. > Personally, especially considering the current landscape, I believe that statement is simply wrong. Saying "just bug fixes" for 2.4 for some unknown number of months is just flat out incorrect when we haven't even EOLed it and, in fact, when 2.2 is still available, supported and would be in that self- same mode. "actually end enhancements alltogether against 2.4" at this point is a sure fire way to completely kill Apache httpd and is not required in the least. You seem to forget that people can, and want, to do both. We do not, and should not, control and restrict, without very good, solid, reasons, what people do on their own free time here. Just as it is "unwise" or "authoritarian" to "block" work on trunk, it is the same for 2.4, considering the situation that we are in *right now*. We need to continue to be relevant and innovative in 2.4 while we are, at the same time, creating the next rev. Suffocating one before its "replacement" is even in pre-alpha stage is simply not needed nor is it a wise move project-management-wise. It is unfair to our users. It's like saying you can't have another kid until your youngest is 18 :) Cheers.
Re: Post 2.4.25
Well, since I am actively working on trunk, I am obviously interested in seeing continued work being done on it and the work being usable to our users in a timely fashion. Since backports to 2.2 have not affected work on 2.4 or trunk, it is obvious as well that any backport efforts for 2.4 won't be any issue at all, so work on trunk will be unrestricted. I hope your enthusiasm regarding timeframes is warranted and accurate. Obviously my efforts are directed towards what is best for our community and am looking forward to how we continue with next gen. On 2016-12-23 17:50 (-0500), William A Rowe Jr wrote: > Just a couple quick thoughts... > > On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote: > > > As I have also stated, my personal belief is that > 2.4 is finally reaching some traction, and if we > "turn off" development/enhancement of 2.4, we will > stop the uptake of 2.4 in its track. > > > I think you might be misconstruing our flaws in httpd with our version > numbering scheme. > > There is only one other project with our longevity that refuses to bump > version majors, and they are suddenly 2 versions ahead of us in only a few > short years. If you haven't guessed, that's the Linux Kernel. > > > . We need to keep > 2.4 viable and worthwhile > > > So long as we fix the bugs, it is. > > Maybe the whole thing revolves around us mistakenly > using the term "2.6/3.0"... > > > I ceased doing this. After another admonishment that version numbers are > cheap, and out team's concensus that treating r->uri as a decoded value was > a wrong call, we won't have a release that can be called 2.next. > > During its incubation of alphas and betas, it still remains 2.5.x, but on > completion I can't imagine calling this 2.6. This will be a fundamental > change that requires a 3.0 designation. > > I don't see us taking shortcuts to get to that point, but believe it is a > change that will occur in a very short timespan, because several committers > want to see this happen. > > So long as it is foretold that nobody is blocking 3.0, unlike 3 years ago, > I expect that sort of energy and enthusiasm to take hold toward a GA > release in the next six months, if we don't get bogged down in more > backport type of activity. >
Re: Post 2.4.25
Just a couple quick thoughts... On Dec 23, 2016 2:55 PM, "Jim Jagielski" wrote: As I have also stated, my personal belief is that 2.4 is finally reaching some traction, and if we "turn off" development/enhancement of 2.4, we will stop the uptake of 2.4 in its track. I think you might be misconstruing our flaws in httpd with our version numbering scheme. There is only one other project with our longevity that refuses to bump version majors, and they are suddenly 2 versions ahead of us in only a few short years. If you haven't guessed, that's the Linux Kernel. . We need to keep 2.4 viable and worthwhile So long as we fix the bugs, it is. Maybe the whole thing revolves around us mistakenly using the term "2.6/3.0"... I ceased doing this. After another admonishment that version numbers are cheap, and out team's concensus that treating r->uri as a decoded value was a wrong call, we won't have a release that can be called 2.next. During its incubation of alphas and betas, it still remains 2.5.x, but on completion I can't imagine calling this 2.6. This will be a fundamental change that requires a 3.0 designation. I don't see us taking shortcuts to get to that point, but believe it is a change that will occur in a very short timespan, because several committers want to see this happen. So long as it is foretold that nobody is blocking 3.0, unlike 3 years ago, I expect that sort of energy and enthusiasm to take hold toward a GA release in the next six months, if we don't get bogged down in more backport type of activity.
Re: Post 2.4.25
Personally, I don't think that backporting stuff to 2.4 prevents or disallows development on 2.6/3.0. In fact, I think it helps. We can easily do both... after all, we are still "working" on 2.2. As I have also stated, my personal belief is that 2.4 is finally reaching some traction, and if we "turn off" development/enhancement of 2.4, we will stop the uptake of 2.4 in its track. We need to keep 2.4 viable and worthwhile we, at the same time, work on 2.6/3.0. I think we all understand that getting 2.6/3.0 out will not be a quick and/or painless action. Maybe the whole thing revolves around us mistakenly using the term "2.6/3.0"... I seen trunk as something that could become 2.6 in "short order", if that's the direction we want to go. But there is also the need and desire to really clean-up the codebase (r->uri is the common example used), which means a codebase which is more 3.0 related, and therefore, more extensive and thus taking more time. However, by us using the term "2.6/3.0" it muddies the water, and implies that 2.6 could be much more pervasive that it already is. The long and short is that there is good stuff in trunk. It should be available to our users sooner rather than later. If you want to call that 2.6, fine. What I don't want to see, since I don't think it is a viable solution, is for us to say "OK, let's tag trunk as 2.5 with the goal of getting 2.6 out soon... But hold on, this is broken and we need to completely refactor this. And this is weird, let's strip this out and replace it with this... And while we are at it, let's change this to do that" with the end result that 2.5/2.6 takes ages and 2.4 is left fallow. And, to be honest, I think that is exactly what will happen. The turd will never be polished enuff. And our community suffers. So, to make it crystal clear, I am 100% FOR httpd-next-gen. All I am saying is that we have an existing user base which is still mostly on 2.2, much less 2.4, and they are currently at a disadvantage by not having access to the latest and greatest stuff which is locked away in trunk and could be available for them, *while httpd-next-gen is being worked in parallel*. Nothing is preventing people from playing on trunk... But my feeling is that most people like hacking code that people eventual run in short order and in a timely timeframe. Waiting 6-12-18 months for "new features" is how commercial s/w works, not FOSS. https://w3techs.com/technologies/details/ws-apache/2/all I will ignore the likelihood that httpd-next-gen will require APR 2.0 which may also take a long time to be released. > On Dec 23, 2016, at 3:28 PM, William A Rowe Jr wrote: > > On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski wrote: > For me, it would be moving as much as we can from > trunk to 2.4 > > -1. To echo your frequent use of media to emphasize > the point, with a song nearly as old as us; > https://www.youtube.com/watch?v=EsCyC1dZiN8 > > Next step is to actually end enhancements alltogether > against 2.4 (we've done that some time ago, security > issues notwithstanding, on 2.2), and push all of the > enhancement effort towards 3.0 (2.5-dev). Of course, > we should continue to pick up bug fixes and help those > still on 2.4 have a good day. > > Let those users looking for cool new things pick up > the 3.0 release. > > Or else you are kicking 'everything we can't' further > down the road, again dismissing all of the activity > of so many of our fellow committers. Stale stuff on > trunk/ now dates to over 4 years ago. > > That state of things simply sucks. >
Re: Post 2.4.25
On Fri, Dec 23, 2016 at 2:20 PM, Jim Jagielski wrote: > For me, it would be moving as much as we can from > trunk to 2.4 -1. To echo your frequent use of media to emphasize the point, with a song nearly as old as us; https://www.youtube.com/watch?v=EsCyC1dZiN8 Next step is to actually end enhancements alltogether against 2.4 (we've done that some time ago, security issues notwithstanding, on 2.2), and push all of the enhancement effort towards 3.0 (2.5-dev). Of course, we should continue to pick up bug fixes and help those still on 2.4 have a good day. Let those users looking for cool new things pick up the 3.0 release. Or else you are kicking 'everything we can't' further down the road, again dismissing all of the activity of so many of our fellow committers. Stale stuff on trunk/ now dates to over 4 years ago. That state of things simply sucks.
Post 2.4.25
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.
Re: [DISCUSS] commit messages on backports
For the record, this is what I use: http://home.apache.org/~jim/code/svn.merge Most likely I will change it to have it accept $1 as the names of people to mark as "Reviewed by" via a simple cut/paste of the line from STATUS. > On Dec 23, 2016, at 8:36 AM, Eric Covener wrote: > > In a branch of a private discussion, some issues with how backports > are committed was raised. > > IMO, our use of STATUS kind of makes the current Reviewed By: a little > misleading in http://people.apache.org/~jorton/svn.merge > > * My older copy of the script doesn't have it at all, and I rarely > edit the "clog" it generates -- meaning I almost never capture the > original reviewers in the commit log. > > * Jim had modified his copy, presumably related to the same confusion > vs. what we call the reviewers in STATUS, but it introduced a > different misleading overlap when the work to port a fix was > noteworthy. > > > Do we want to call the list of reviewers from STATUS mandatory in the > commit to the stable branches? > > I am personally -0 on _requiring_ it as STATUS and backporting can > already be a bit tedious, and ultimately most reviews seem to be > desk-checks. I wouldn't mind if svn.merge required more input and > stopped me from breaking a rule though. > > > -- > Eric Covener > cove...@gmail.com
[DISCUSS] commit messages on backports
In a branch of a private discussion, some issues with how backports are committed was raised. IMO, our use of STATUS kind of makes the current Reviewed By: a little misleading in http://people.apache.org/~jorton/svn.merge * My older copy of the script doesn't have it at all, and I rarely edit the "clog" it generates -- meaning I almost never capture the original reviewers in the commit log. * Jim had modified his copy, presumably related to the same confusion vs. what we call the reviewers in STATUS, but it introduced a different misleading overlap when the work to port a fix was noteworthy. Do we want to call the list of reviewers from STATUS mandatory in the commit to the stable branches? I am personally -0 on _requiring_ it as STATUS and backporting can already be a bit tedious, and ultimately most reviews seem to be desk-checks. I wouldn't mind if svn.merge required more input and stopped me from breaking a rule though. -- Eric Covener cove...@gmail.com
Re: T&R of 2.4.24
> On Dec 23, 2016, at 2:32 AM, William A Rowe Jr wrote: > > > I hope you sort this out in your ombudsman role, because this is the > test of whether you understand ASF responsibilities, both legally, > and in the sense of our entire ecosystem, and the will of your specific > project who had a very firm position, before you undermined it. > > Cheers, and a Merry Christmas! Bill, puhlease. Stick and carrot? Really? Anyway, this seems appropriate: " 'Saruman, Saruman!' said Gandalf, still laughing. 'Saruman, you missed your path in life. You should have been the king's jester and earned your bread, and stripes too, by mimicking his counsellors. Ah me!' he paused, getting the better of his mirth. 'Understand one another? I fear I am beyond your comprehension. But you, Saruman, I understand now too well. I keep a clearer memory of your arguments, and deeds, than you suppose. When last I visited you, you were the jailor of Mordor, and there I was to be sent. Nay, the guest who escaped from the roof, will think twice before he comes back in by the door.' " I will give your comments the weight they deserve.
