Re: Thoughts on 2.5.0

On 10/24/2017 11:45 AM, William A Rowe Jr wrote: On Tue, Oct 24, 2017 at 12:35 PM, Jim Jagielski wrote: That is way when we backport we transition to RTC, because we want to ENSURE it's been reviewed. Wrong. I was there. RTC was adopted in order to ensure both the

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

> On Oct 24, 2017, at 4:16 PM, Yann Ylavic wrote: > > > Meaning that we now have a granularity of 10KB (instead of previous > 100B, max) before a balancer member can take over the previous one (I > wondered why several successive small requests were always reaching > the

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

As you said, the external representation as a float is syntactic sugar. But the patch breaks that. Someone enters in, for example, 2.50 and what's displayed in 250, instead of 2.50. Since all this is normalized by how ldfactor is USED, the algos still work, but are now more granular, which is

Re: Pruning working branches (Was: Re: Why?)

On Tue, Oct 24, 2017 at 8:11 AM, William A Rowe Jr wrote: > On Tue, Oct 24, 2017 at 3:28 AM, Steffen wrote: >> >> On Tuesday 24/10/2017 at 10:26, Steffen wrote: >> >> Can someone clean up the not needed anymore backports/branches >>

Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

On Tue, Oct 24, 2017 at 3:28 PM, Jim Jagielski wrote: > I don't understand this patch. It looks like we are no lingering externally > representing ldfactor as a float (e.g.: 2.50). Is that right? If so, > I'm not sure why... It seems to me that ldfactor expressed as "float" is

Re: Thoughts on 2.5.0

> On 24 Oct 2017, at 14:42, Jim Jagielski wrote: > > I would like to start a discussion on 2.5.0 and give > some insights on my thoughts related to it. > > First and foremost: there is cool stuff in 2.5.0 > that I really, REALLY wish were in a releasable, usable > artifact.

Re: Thoughts on 2.5.0

On Tue, Oct 24, 2017 at 1:45 PM, William A Rowe Jr wrote: > > Proceeding as documented and practiced, between trunk and 2.6.0 tag, > we operate under RTC until the committee adopts a rewritten policy. under CTR, of course :)

Re: Thoughts on 2.5.0

On Tue, Oct 24, 2017 at 12:35 PM, Jim Jagielski wrote: > >> That's what commit-then-review means. If you failed to >> review it, you now have a six year knowledge gap and review to >> conduct. That's not sustainable, nobody at the project has that kind >> of time. > > "Review"

Re: Thoughts on 2.5.0

On Tue, Oct 24, 2017 at 12:39 PM, Jim Jagielski wrote: > On Tue, Oct 24, 2017 at 11:20 AM, William A Rowe Jr > wrote: >> On Tue, Oct 24, 2017 at 8:42 AM, Jim Jagielski wrote: >>> >>> Another would be to look at some of the items

Re: Thoughts on 2.5.0

> > I am not doing it for 2.4.x, and will continue not to do it for 2.4.x, > because I won't contribute to further destabilizing 2.4.x current > releases. So you refuse to help stabilize the 2.4.x tree, but then complain that the 2.4.x tree is unstable. OK. That's fine. Your cycles are yours to

Re: Thoughts on 2.5.0

> That's what commit-then-review means. If you failed to > review it, you now have a six year knowledge gap and review to > conduct. That's not sustainable, nobody at the project has that kind > of time. "Review" does not have a time limit. Anyone can, and should, review whenever they wish.

[Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

I'd like to propose the following, so we can decide on what course to chart between here and there. Today we are at 2.5.0-dev, slated to become 2.5.0 non-GA release. Through a series of non-GA releases, 2.5.x is eventually approved to become the next 'evens' GA release. What we number that by

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

On Tue, Oct 24, 2017 at 3:12 AM, Stefan Eissing wrote: > FTR: I refuse any discussion where people, already in the initial > statements, discuss each others merit and downfalls and whatnot. > > If you want to talk about technical stuff and/or propose a project plan,

Re: Thoughts on 2.5.0

I will preface by stating that you are referring to 2.6.0 or 3.0.0, our next GA, which is not yet what I've suggested on list. I'll start another thread on 2.5.0 development branch, and run with your discussion of the next GA... On Tue, Oct 24, 2017 at 8:42 AM, Jim Jagielski

AW: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

Same here: I don't see why the lbmethods rely on it between 1 and 100 and why they cannot work with 100 till 1 Effectively we kill values like 2.5 and the new comment > it is a number between 1 and 100 (or 0.01 and 1.0). is wrong since 0.01 is not an allowed value (it will fail the check

Thoughts on 2.5.0

I would like to start a discussion on 2.5.0 and give some insights on my thoughts related to it. First and foremost: there is cool stuff in 2.5.0 that I really, REALLY wish were in a releasable, usable artifact. Up to now, we've been doing these as backports to the 2.4.x tree with, imo at least,

AW: Pruning working branches (Was: Re: Why?)

> -Ursprüngliche Nachricht- > Von: William A Rowe Jr [mailto:wr...@rowe-clan.net] > Gesendet: Dienstag, 24. Oktober 2017 15:12 > An: httpd > Betreff: Pruning working branches (Was: Re: Why?) > > On Tue, Oct 24, 2017 at 3:28 AM, Steffen

Pruning working branches (Was: Re: Why?)

On Tue, Oct 24, 2017 at 3:28 AM, Steffen wrote: > > On Tuesday 24/10/2017 at 10:26, Steffen wrote: > > Can someone clean up the not needed anymore backports/branches > http://svn.apache.org/viewvc/httpd/httpd/branches/ > httpd 2.4.1 was tagged at r1243503. I'd propose

Re: Simplify download distribution directory by dropping sha1 hashes?

On Tue, Oct 24, 2017 at 2:50 AM, Luca Toscano wrote: > > 2017-10-23 20:36 GMT+02:00 William A Rowe Jr : >> >> HTTPD team, >> >> Since our downloads are to be authenticated by their .asc PGP >> signatures, and the hashes simply serve as checksums, is it

Re: Decrypting mod_session-created cookie

Hi Mikhail, I tried your code to decode the session cookie generated with mod_session, but unfortunately does not seem to work properly. The openssl_decrypt ($ ct, $ cipher, $ key, OPENSSL_RAW_DATA, $ iv) function always return false ... Could it be due to salt calculation? Thank you D.

Re: Simplify download distribution directory by dropping sha1 hashes?

> Am 23.10.2017 um 20:36 schrieb William A Rowe Jr : > > HTTPD team, > > Since our downloads are to be authenticated by their .asc PGP > signatures, and the hashes simply serve as checksums, is it reasonable > to offer only MD5 and SHA256 at this point? > > Anyone without

Re: Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?}today]

wrong link where to clean up: http://svn.apache.org/viewvc/httpd/httpd/branches/ On Tuesday 24/10/2017 at 10:26, Steffen wrote: Can someone clean up the not needed anymore backports/branches at http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby=date On Tuesday 24/10/2017 at

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?}today]

Can someone clean up the not needed anymore backports/branches at http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby=date On Tuesday 24/10/2017 at 10:12, Stefan Eissing wrote: FTR: I refuse any discussion where people, already in the initial statements, discuss each others merit

Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]

FTR: I refuse any discussion where people, already in the initial statements, discuss each others merit and downfalls and whatnot. If you want to talk about technical stuff and/or propose a project plan, start a new thread without all that destructive crap I will not waste any more time than

Re: Simplify download distribution directory by dropping sha1 hashes?

2017-10-23 20:36 GMT+02:00 William A Rowe Jr : > HTTPD team, > > Since our downloads are to be authenticated by their .asc PGP > signatures, and the hashes simply serve as checksums, is it reasonable > to offer only MD5 and SHA256 at this point? > > Anyone without SHA256