Re: Thoughts on 2.5.0

2017-10-24 Thread Jacob Champion 

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
reliability but moreso, the compatibility of changes during a given
x.y major/minor release cycle. CTR existed to make forward progress
and get out of our developers' way.


I'm not really sure Jim's statement here is "wrong". Regardless of 
historical context. We use RTC when we want to guarantee review.



You are suggesting a change of policy. It
is not policy to use RTC to get from trunk to 2.6.0, and will not
become policy without a vote for such a change by the PMC.


I'm not entirely convinced Jim is suggesting a change in policy, as you 
say. But in any case, I would be +1 to such a change. We should not be 
releasing a 2.6.x that contains unreviewed code.


--Jacob

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

2017-10-24 Thread Jim Jagielski 

> 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 same backend...).
> 

long-term patterns is what the methods provide... you can't guarantee
short-term behavior.

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

2017-10-24 Thread Jim Jagielski 
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 what we wanted.

> On Oct 24, 2017, at 4:16 PM, Yann Ylavic  wrote:
> 
> 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 just syntactic
> sugar, it's still an "int" in struct proxy_worker_shared.
> 
> The lbmethods' algorithms were previously given value between 1 and
> 100, and since 2.4.28 this value is effectively between 100 and 1.
> For, e.g. bytraffic, this changes the below computation a bit:
> 
>mytraffic = ((*worker)->s->transferred / (*worker)->s->lbfactor) +
>((*worker)->s->read / (*worker)->s->lbfactor);
> 
> 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 same backend...).
> 
> It's fine that users can now use decimal numbers between 1.0 and 10.0
> (or still non-decimals between 1 and 100 as before, though they
> probably shouldn't mix both), but it shouldn't change lbmethods
> behaviour IMHO.
> 
> The other builtin lbmethods don't seem impacted though (they only sum
> up lbfactor), so maybe we need something for bytraffic only...

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

2017-10-24 Thread William A Rowe Jr 
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
>>  http://svn.apache.org/viewvc/httpd/httpd/branches/
>>
>
> httpd 2.4.1 was tagged at r1243503.
>
> I'd propose we start by pruning all working branches not updated since this 
> tag.
>
> Thoughts?

To clarify; this list consists of;

Last rev – Last modified – Branch

 371484  11 years  async-read-dev/
 367678  11 years  authz-dev/
 446636  11 years  cache-refactor/
 369019  11 years  execd-dev/
 393955  11 years  fcgi-proxy-dev/
 8095458 years  httpd-2.2-proxy/
 431328  11 years  httpd-proxy-scoreboard/
 1200612  5 years  input-filter-dev/
 171035  12 years  listen-protocol/
 151147  12 years  proxy-reqbody/
 1150173  6 years  revert-ap-ldap/
 7236558 years  wombat-integration/

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

2017-10-24 Thread Yann Ylavic 
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 just syntactic
sugar, it's still an "int" in struct proxy_worker_shared.

The lbmethods' algorithms were previously given value between 1 and
100, and since 2.4.28 this value is effectively between 100 and 1.
For, e.g. bytraffic, this changes the below computation a bit:

mytraffic = ((*worker)->s->transferred / (*worker)->s->lbfactor) +
((*worker)->s->read / (*worker)->s->lbfactor);

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 same backend...).

It's fine that users can now use decimal numbers between 1.0 and 10.0
(or still non-decimals between 1 and 100 as before, though they
probably shouldn't mix both), but it shouldn't change lbmethods
behaviour IMHO.

The other builtin lbmethods don't seem impacted though (they only sum
up lbfactor), so maybe we need something for bytraffic only...

Re: Thoughts on 2.5.0

2017-10-24 Thread Mark Blackman 


> 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. Up to now, we've been doing these as backports
> to the 2.4.x tree with, imo at least, good success.
> 
> So I think the main questions regarding 2.5.0 is a list
> of items/issues that simply *cannot* be backported, due
> to API/ABI concerns. And then gauge the "value" of
> the items on that list.
> 
> Another would be to look at some of the items currently
> "on hold" for backporting, due to outstanding questions,
> tech issues, more needed work/QA, etc... IMO, if these
> backports lack "support" for 2.4.x, then I wonder how
> "reliable" they are (or how tested they are) in the 2.5.o
> tree. And if the answer is "we pull them out of 2.5.0"
> then the question after that is what really *are* the
> diffs between 2.5.0 and 2.4.x... If, however, the
> answer is "tagging 2.5.0 will encourage us to address
> those issues" then my question is "Why aren't we doing
> that now... for 2.4.x".
> 
> And finally: 2.4.x is now, finally, being the default
> version in distros, being the go-to version that people
> are using, etc... I would like us to encourage that
> momentum.

As an observer, I’d like to ask what your goals are for these branches and what 
kinds of expectations would you like consumers of these branches to have?

- Mark

Re: Thoughts on 2.5.0

2017-10-24 Thread William A Rowe Jr 
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

2017-10-24 Thread William A Rowe Jr 
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" does not have a time limit. Anyone can, and should, review
> whenever they wish.

Correct.

> Just because something has been folded
> in does not mean it has necessarily been reviewed.

Nor does it mean it hasn't.

> 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
reliability but moreso, the compatibility of changes during a given
x.y major/minor release cycle. CTR existed to make forward progress
and get out of our developers' way.

We did not get to 2.0.35 GA under RTC. We did not get to 2.2.0 GA
under RTC, we did not get to 2.4.1 GA under RTC.

Proceeding as documented and practiced, between trunk and 2.6.0 tag,
we operate under RTC until the committee adopts a rewritten policy.

> Just tagging/releasing something that has been CTR does not
> automatically nor magically make all the commits "reviewed".

Nor does it indicate they were *not* reviewed. It is not our
responsibility to account to you what we collectively have reviewed
over the past six years because others failed to review what is
committed to the repository. You are suggesting a change of policy. It
is not policy to use RTC to get from trunk to 2.6.0, and will not
become policy without a vote for such a change by the PMC.

You are contriving policy; I don't know what your agenda is until you
put forward a policy change which we can debate as a community. But I
am proceeding under current policy and the mechanisms which ultimately
got us to 2.0, 2.2 and 2.4.

> Nor does it mean that people cannot re-review and even veto
> the commit.
>
> These are bits, not concrete.

Agreed.

Re: Thoughts on 2.5.0

2017-10-24 Thread William A Rowe Jr 
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 currently
>>> "on hold" for backporting, due to outstanding questions,
>>> tech issues, more needed work/QA, etc... IMO, if these
>>> backports lack "support" for 2.4.x, then I wonder how
>>> "reliable" they are (or how tested they are) in the 2.5.o
>>> tree. And if the answer is "we pull them out of 2.5.0"
>>> then the question after that is what really *are* the
>>> diffs between 2.5.0 and 2.4.x... If, however, the
>>> answer is "tagging 2.5.0 will encourage us to address
>>> those issues" then my question is "Why aren't we doing
>>> that now... for 2.4.x".
>>
>> 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.

Because introducing unwise enhancements makes it so; because branch
hygiene makes it so. I'm not going to battle either windmill, since
current practice dictates that it is a losing battle.

I'll continue to review and vote up bug fixes. I'll continue to push
bugfixes I write at 2.4.x. I'll continue to skim enhancements for
breakage that I can spot.

> OK. That's fine. Your cycles are yours to use as you wish.

There we go again with the personal swipes. Please speak to process
and code, not people.

This is exactly the point, of course. Those who wanted to maintain 2.2
did so, irrespective of what those other committers, who could not
have cared less, chose to work on. And so it will be after 2.4,
committers can keep maintaining 2.4, during the 2.5 cycle and beyond
2.6.0/3.0.0. Those who simply want to develop can develop.

Re: Thoughts on 2.5.0

2017-10-24 Thread Jim Jagielski 
> 
> 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 use as you wish.

Re: Thoughts on 2.5.0

2017-10-24 Thread Jim Jagielski 

>  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. Just because something has been folded
in does not mean it has necessarily been reviewed. That is way
when we backport we transition to RTC, because we want to ENSURE
it's been reviewed.

Just tagging/releasing something that has been CTR does not
automatically nor magically make all the commits "reviewed".
Nor does it mean that people cannot re-review and even veto
the commit.

These are bits, not concrete.

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

2017-10-24 Thread William A Rowe Jr 
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 default is
2.6.0, or if the group decides the changes are significant enough,
3.0.0.

What I propose now is that we designate all 2.5.x releases as -alpha
*until the list decides the API (not ABI) changes are complete*.
That's the only process change.

We track this through STATUS, with a vote to promote API-changing
proposals to SHOWSTOPPERs to -beta. So developers will be aware when
we declare -beta that we will no longer change the API for them, and
their modules must conform to the new API, barring any radical
discoveries that prevent us from shipping that API (which might then
return us to the -alpha phase.)

E.g. we had a security@ discussion about changing the handling of URI
significantly so that the meaning of escaped vs. unescaped characters
is never obtuse. There are several proposals on that table (embargoed
at that time waiting for our HTTP protocol correctness patches to be
published.) Those need to come here to dev@. One of them will land in
STATUS, and will inevitably be upvoted to SHOWSTOPPER status;
2.5.x-beta shouldn't happen, IMO, until some code and structure
changes to accomplish this has been accepted.

Because it is CTR, we don't need STATUS for patch voting, but I do
think we want STATUS to identify what is the minimum changes needed to
declare the next API/ABI-breaking release complete and ready for
-beta.

Thoughts?

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

2017-10-24 Thread William A Rowe Jr 
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,
> start a new thread without all that destructive crap I will not waste
> any more time than this mail about.

That's exactly what I did;

On Fri, Oct 13, 2017 at 8:19 AM, William A Rowe Jr  wrote:
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
>
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
>
> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.

There was no animus or personality involved in this statement. Follow
the thread to find out where it "broke" and who broke it.

I will kill this thread; I should have limited it to responding that
our ruleset inhibits vetoes of tags and releases; then a second fresh
thread not to anyone's comment in particular explaining the basis of
2.5.0-alpha. My bad, I apologize for mixing the two, and will more
carefully avoid this in the future.

Re: Thoughts on 2.5.0

2017-10-24 Thread William A Rowe Jr 
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  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. Up to now, we've been doing these as backports
> to the 2.4.x tree with, imo at least, good success.

The 2.4.x release series has a >50% regression rate release by
release, comparing released 2.4.n to 2.4.prev. I don't consider that
'good'. This is because 2.4 is not a maintenance branch, and is
therefore not stable. But we don't have to extend this conversation
because I brought up the concern previously and the concern was
rejected. A 2.5.x alpha preview branch *with community testers* would
have avoided a great number of these regressions, if the community had
a chance to test and provide feedback.

> So I think the main questions regarding 2.5.0 is a list
> of items/issues that simply *cannot* be backported, due
> to API/ABI concerns. And then gauge the "value" of
> the items on that list.

Disagreed. That the code was committed and passively vetoed due to an
unwillingness of the project to release it.

httpd 2.4.0 was forked at r1200449. This happened 6 years ago as of
this coming Nov 10th.

What is that code? Discounting all changes to docs/, all changes in
whitespace, line endings and propchanges, the remaining delta is;

 + 36654 lines + 1014607 non-whitespace characters
 - 17198 lines - 610777 non-whitespace characters

> Another would be to look at some of the items currently
> "on hold" for backporting, due to outstanding questions,
> tech issues, more needed work/QA, etc... IMO, if these
> backports lack "support" for 2.4.x, then I wonder how
> "reliable" they are (or how tested they are) in the 2.5.o
> tree. And if the answer is "we pull them out of 2.5.0"
> then the question after that is what really *are* the
> diffs between 2.5.0 and 2.4.x... If, however, the
> answer is "tagging 2.5.0 will encourage us to address
> those issues" then my question is "Why aren't we doing
> that now... for 2.4.x".

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. It takes a serious vulnerability for me to risk the
stability of 2.4.x, something on the order of the HTTP conformance
issues we faced over the past year. Once again, 4 1/2 year old code
had never been shared with the community, once again that ignored code
contained defects that would have been noticed in a public -alpha over
a four year period.

I am for doing this necessary review for 2.5.0, but all the code was
reviewed. 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. As PMC and committers, we had these commits in our inboxes.
We questioned committers about changes that looked incorrect. We
vetoed some changes that didn't fit or wouldn't work.

It's over-past time for that code, those committers' efforts to see
the light of day, even as an alpha for the time being. Any argument to
the contrary or new layers of process is disingenuous at best, and
obstructionist at worst.

> And finally: 2.4.x is now, finally, being the default
> version in distros, being the go-to version that people
> are using, etc... I would like us to encourage that
> momentum.

No, 2.4.current is not the default. Our current n.n.n at the time
these distributions decided to freeze is the distributed version, then
they pick up security backports.

RHEL 7 and CentOS 7 are still 2.4.6. Ubuntu 16.04 is still 2.4.7, or
2.4.10 from backports, xenial is 2.4.18 and zesty is 2.4.25

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

57% of all the deployed httpd 2.4 are one of the first four ancient
versions, and 67% if you count 2.4.25 (likely a mix of zesty and
non-zesty not updated in 4 months). Of that, 2.4 captures 51% and 49%
are older still (2.2/2.0); we can slice those adoption numbers in
half.

So 1/3rd of httpd deployments are on one of the five versions
distributed in these five operating system distributions.

Only 11% of the deployments have been refreshed since our June release.

If you are talking distributions, they will be at whatever we give
them once they ship. They won't pick up our new features until they
are ready to tag a new OS release, so 'distros', at least 'os distros'
is non sequitur. If you are talking httpd binaries, every creator has
their own schema; at Pivotal (and JBoss and similar, I suspect) we
prepared to pick up all releases but dropped the ones with quickly
identified

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

2017-10-24 Thread Plüm , Rüdiger , Vodafone Group 
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 below).

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Jim Jagielski [mailto:j...@jagunet.com]
> Gesendet: Dienstag, 24. Oktober 2017 15:29
> An: dev@httpd.apache.org
> Cc: c...@httpd.apache.org
> Betreff: Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES
> modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c
> 
> 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...
> 
> > On Oct 24, 2017, at 6:50 AM, yla...@apache.org wrote:
> >
> > Author: ylavic
> > Date: Tue Oct 24 10:50:34 2017
> > New Revision: 1813167
> >
> > URL: http://svn.apache.org/viewvc?rev=1813167=rev
> > Log:
> > mod_proxy_balancer: fix runtime lbfactor value changed in 2.4.28.
> >
> > It is assumed to be between 1 and 100 by lbmethods, so normalize it
> > accordingly.
> >
> >
> > Modified:
> >httpd/httpd/trunk/CHANGES
> >httpd/httpd/trunk/modules/proxy/mod_proxy.c
> >httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
> >
> > Modified: httpd/httpd/trunk/CHANGES
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1813167=18
> 13166=1813167=diff
> >
> 
> ==
> > --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> > +++ httpd/httpd/trunk/CHANGES [utf-8] Tue Oct 24 10:50:34 2017
> > @@ -1,6 +1,10 @@
> >  -*- coding:
> utf-8 -*-
> > Changes with Apache 2.5.0
> >
> > +  *) mod_proxy_balancer: fix runtime lbfactor value changed in
> 2.4.28. It is
> > + assumed to be between 1 and 100 by lbmethods, so normalize it
> accordingly.
> > + [Yann Ylavic]
> > +
> >   *) mod_md: v1.0.1, ServerName/Alias names from pure-http: virtual
> hosts are no longer
> >  auto-added to a Managed Domain. Error counts of jobs are
> presisted. When the server
> >  restarts (gracefully) any errored staging areas are purged to
> reset the signup/renewal
> >
> > Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c
> ?rev=1813167=1813166=1813167=diff
> >
> 
> ==
> > --- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Tue Oct 24 10:50:34
> 2017
> > @@ -104,13 +104,13 @@ static const char *set_worker_param(apr_
> >
> > if (!strcasecmp(key, "loadfactor")) {
> > /* Normalized load factor. Used with BalancerMember,
> > - * it is a number between 1 and 100.
> > + * it is a number between 1 and 100 (or 0.01 and 1.0).
> >  */
> > double fval = atof(val);
> > ival = fval * 100.0;
> > if (ival < 100 || ival > 1)
> > return "LoadFactor must be a number between 1..100";
> > -worker->s->lbfactor = ival;
> > +worker->s->lbfactor = ival / 100;
> > }
> > else if (!strcasecmp(key, "retry")) {
> > /* If set it will give the retry timeout for the worker
> > @@ -2883,7 +2883,7 @@ static int proxy_status_hook(request_rec
> > ap_rvputs(r, ap_proxy_parse_wstatus(r->pool, *worker),
> NULL);
> > ap_rvputs(r, "", (*worker)->s->route, NULL);
> > ap_rvputs(r, "", (*worker)->s->redirect,
> NULL);
> > -ap_rprintf(r, "%.2f",
> (float)((*worker)->s->lbfactor)/100.0);
> > +ap_rprintf(r, "%d", (*worker)->s-
> >lbfactor);
> > ap_rprintf(r, "%d", (*worker)->s->lbset);
> > ap_rprintf(r, "%" APR_SIZE_T_FMT "",
> >(*worker)->s->elected);
> >
> > Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_b
> alancer.c?rev=1813167=1813166=1813167=diff
> >
> 
> ==
> > --- httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c Tue Oct 24
> 10:50:34 2017
> > @@ -1093,11 +1093,10 @@ static int balancer_handler(request_rec
> > ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(01192)
> "settings worker params");
> >
> > if ((val = apr_table_get(params, "w_lf"))) {
> > -int ival;
> > double fval = atof(val);
> > -ival = fval * 100.0;
> > +int ival = fval * 100.0;
> > if (ival >= 100 && ival <= 1) {
> > -wsel->s->lbfactor = ival;

Thoughts on 2.5.0

2017-10-24 Thread Jim Jagielski 
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, good success.

So I think the main questions regarding 2.5.0 is a list
of items/issues that simply *cannot* be backported, due
to API/ABI concerns. And then gauge the "value" of
the items on that list.

Another would be to look at some of the items currently
"on hold" for backporting, due to outstanding questions,
tech issues, more needed work/QA, etc... IMO, if these
backports lack "support" for 2.4.x, then I wonder how
"reliable" they are (or how tested they are) in the 2.5.o
tree. And if the answer is "we pull them out of 2.5.0"
then the question after that is what really *are* the
diffs between 2.5.0 and 2.4.x... If, however, the
answer is "tagging 2.5.0 will encourage us to address
those issues" then my question is "Why aren't we doing
that now... for 2.4.x".

And finally: 2.4.x is now, finally, being the default
version in distros, being the go-to version that people
are using, etc... I would like us to encourage that
momentum.

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

2017-10-24 Thread Plüm , Rüdiger , Vodafone Group 


> -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  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 we start by pruning all working branches not updated since
> this tag.
> 
> Thoughts?

+1

Regards

Rüdiger

Pruning working branches (Was: Re: Why?)

2017-10-24 Thread William A Rowe Jr 
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 we start by pruning all working branches not updated since this tag.

Thoughts?

Re: Simplify download distribution directory by dropping sha1 hashes?

2017-10-24 Thread William A Rowe Jr 
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 reasonable
>> to offer only MD5 and SHA256 at this point?
>>
>> Anyone without SHA256 (rare, I'd expect) can use MD5 as the simplest
>> supported checksum. All others should apply the strongest hash
>> validation.
>>
>> Thoughts?
>
> +1, I'd also get rid of MD5 since I don't expect anybody relying on it but I
> might be wrong :)

As much as I'd like to, it wasn't long ago I was still building httpd on HP/UX,
AIX and other oddballs. Having some old-school hash while httpd still
compiles on those boxes seems rational.

Re: Decrypting mod_session-created cookie

2017-10-24 Thread Cadorago 
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.



--
Sent from: 
http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: Simplify download distribution directory by dropping sha1 hashes?

2017-10-24 Thread Stefan Eissing 


> 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 SHA256 (rare, I'd expect) can use MD5 as the simplest
> supported checksum. All others should apply the strongest hash
> validation.
> 
> Thoughts?
> 
> Bill

+1

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

2017-10-24 Thread Steffen 


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 10:12, 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,

start a new thread without all that destructive crap I will not waste
any more time than this mail about.

Cheers,

Stefan



Am 24.10.2017 um 00:17 schrieb William A Rowe Jr 
:


Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.

The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)

I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.

You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.

This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.

(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.

I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.

http://httpd.apache.org/dev/release.html

By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.

Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.

The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)

As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.



On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  
wrote:


The issue obviously isn't in the *tagging*. It is the unknown
aspect of what is expected AFTER the tagging.

I see the tagging as simply a mechanism to force action
upon the PMC to go down a route which the PMC has not
decided, from what I can tell, to go down. Maybe I'm wrong.
But your reply tends to support that interpretation. The tag, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
from what I can tell, the PMC has not decided that such
a push is warranted/needed/desired/whatever.

So if you want to tag, first generate a roadmap, that can be
shared and discussed with the PMC, and the dev community,
what that 1st step is intended to lead us to. But let's
not pretend that such tagging is simply noting a SVN revision.

You may complain that I "single handedly" do Foo and Bar
and other dictatorial and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
checks... etc...). Even w/ releases and tags I give
people more than 24hours notice. Unless, of course,
your tag was under Lazy Consensus, in which case my
"veto" was valid, if more "strong" than required. In
which

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

2017-10-24 Thread Steffen 


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 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 this mail about.

Cheers,

Stefan



Am 24.10.2017 um 00:17 schrieb William A Rowe Jr 
:


Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.

The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)

I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.

You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.

This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.

(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.

I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.

http://httpd.apache.org/dev/release.html

By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.

Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.

The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)

As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.



On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  
wrote:


The issue obviously isn't in the *tagging*. It is the unknown
aspect of what is expected AFTER the tagging.

I see the tagging as simply a mechanism to force action
upon the PMC to go down a route which the PMC has not
decided, from what I can tell, to go down. Maybe I'm wrong.
But your reply tends to support that interpretation. The tag, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
from what I can tell, the PMC has not decided that such
a push is warranted/needed/desired/whatever.

So if you want to tag, first generate a roadmap, that can be
shared and discussed with the PMC, and the dev community,
what that 1st step is intended to lead us to. But let's
not pretend that such tagging is simply noting a SVN revision.

You may complain that I "single handedly" do Foo and Bar
and other dictatorial and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
checks... etc...). Even w/ releases and tags I give
people more than 24hours notice. Unless, of course,
your tag was under Lazy Consensus, in which case my
"veto" was valid, if more "strong" than required. In
which case, I am sorry for that.

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

2017-10-24 Thread Stefan Eissing 
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 this mail about.

Cheers,

Stefan

> Am 24.10.2017 um 00:17 schrieb William A Rowe Jr :
> 
> Jim, you have very vocally and hostility reacted to *all* discussion
> of improving the release process at the httpd project.
> 
> The project bylaws are clear, no individual PMC member may
> block a release (the PMC chair may, owing to the fact that they
> alone represent the board as the appointed VP, that's another
> topic entirely.)
> 
> I have no evidence that you perceive a problem with the httpd
> release status quo, and no evidence that you have reconsidered
> your positions expressed during the past year, so I presume
> none of these are changed, and further discussion is not
> necessary at this step.
> 
> You've insisted we maintain the status quo with no changes,
> and I'm proceeding based on our historical and documented
> practices to move the project along. This is an obvious case
> of agree-to-disagree, I accept your demand to hold to precedent,
> and will proceed under that structure to ask wiling users to help
> us determine the usability of the current code trunk/. In short,
> you have engendered this solution.
> 
> This is only a starting point, not a result. Multiple -alphas will
> usually occur, and I can't foresee any conclusions on a roadmap
> before the end of the year, and a beta-worthy candidate before
> the end of winter.
> 
> (Northern) winter tends to be a period of greater activity, summers
> are very quiet in comparison. The approach to progress under our
> existing model is incremental; code and release, code and release,
> until the committee agrees that the code is ready to move from an
> -alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
> approach avoids all personal conflicts by getting away from
> people debating opinion or process, and going back to debating
> the features and code.
> 
> I am reading your reply as adding additional process which does
> not exist, and appears to be thrown-up roadblocks. I'll ignore such
> attempts to introduce process until any proposed process has the
> majority +1 support by the project. If others here at httpd want
> to begin defining the structure of 2.6.0/3.0.0 (the next possible
> GA release, because 2.5.x is not GA, by policy), I'm all for it.
> It's not a prereq to begin.
> 
> http://httpd.apache.org/dev/release.html
> 
> By "vetoed tag" it does not mean you can veto a tag. That wording
> means that there is no code at present which carries a veto. I'm
> unaware of any code in trunk that is vetoed in the 2.5.x development
> trunk branch.
> 
> Please inform within 72 hours of what you are vetoing from -alpha
> examination, so that I can remove or route around it and avoid any
> unnecessary tags.
> 
> The rules were designed from day 1 of the ASF as a foundation
> that no one individual can block forward progress of the project,
> any PMC member may branch, or tag. The majority decision of
> the project decides whether that tag is adopted as a release
> (even -alpha requires a majority, 3 +1's!)
> 
> As the saying goes "We won't know till we try"... let's see if we
> have collectively treated trunk/ well, and whether adventurous
> users on the bleeding edge like what they see.
> 
> 
> 
> On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski  wrote:
>> The issue obviously isn't in the *tagging*. It is the unknown
>> aspect of what is expected AFTER the tagging.
>> 
>> I see the tagging as simply a mechanism to force action
>> upon the PMC to go down a route which the PMC has not
>> decided, from what I can tell, to go down. Maybe I'm wrong.
>> But your reply tends to support that interpretation. The tag, per
>> se, is not the goal. The goal is to "push" 2.5.0 when, again
>> from what I can tell, the PMC has not decided that such
>> a push is warranted/needed/desired/whatever.
>> 
>> So if you want to tag, first generate a roadmap, that can be
>> shared and discussed with the PMC, and the dev community,
>> what that 1st step is intended to lead us to. But let's
>> not pretend that such tagging is simply noting a SVN revision.
>> 
>> You may complain that I "single handedly" do Foo and Bar
>> and other dictatorial and dangerous stuff, but AFAIK, I've
>> never done or proposed anything w/o bringing it up
>> to the list 1st (ala PROXY support, mod_wsgi, health
>> checks... etc...). Even w/ releases and tags I give
>> people more than 24hours notice. Unless, of course,
>> your tag was under Lazy Consensus, in which case my
>> "veto" was valid, if more "strong" than required. In
>> which case, I am sorry for that.

Re: Simplify download distribution directory by dropping sha1 hashes?

2017-10-24 Thread Luca Toscano 
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 (rare, I'd expect) can use MD5 as the simplest
> supported checksum. All others should apply the strongest hash
> validation.
>
> Thoughts?
>

+1, I'd also get rid of MD5 since I don't expect anybody relying on it but
I might be wrong :)

Luca