Re: Status for 2.4.20

[Yann Ylavic]

On Wed, Mar 30, 2016 at 11:02 AM, Nick Edwards  wrote:
> So after a thread stop message, why do you feel you need to troll bait them?
> It's clear they both agreed to ignore each other, it's been clear one party
> had no intention on keeping his word (having had myriad of clashes with the
> fool reindl myself on other lists I'm not at all surprised he expected it to
> all one way), so the other advises " gates of hell will open ", so, what's
> your angle?

My angle is that William's warning (seconded by mine, maybe
unnecessarily) also applies to the friend(s) of the one or the other
willing to continue on this road...

Re: Status for 2.4.20

[Nick Edwards]

So after a thread stop message, why do you feel you need to troll bait them?
It's clear they both agreed to ignore each other, it's been clear one party
had no intention on keeping his word (having had myriad of clashes with the
fool reindl myself on other lists I'm not at all surprised he expected it
to all one way), so the other advises " gates of hell will open ", so,
what's your angle? what's the point of your post, posts like yours only
invites trouble. If they don't want to adhere to thread stop William will
wield his big stick as he clams to have, their problem.



On Wed, Mar 30, 2016 at 8:15 AM, Yann Ylavic  wrote:

> On Wed, Mar 30, 2016 at 7:49 AM, William A Rowe Jr 
> wrote:
> > FULL STOP.
>
> Really, NOW, simply don't talk to each other here (this way at least,
> but anyway is fine too since it seems hopeless).
>
> You are able to block each other on your respective networks, well,
> keep reading your logs for bounced emails if it pleases you, but this
> list (or any @a.o one) is definitively not an loop-hole!
>

Re: Status for 2.4.20

[Yann Ylavic]

On Wed, Mar 30, 2016 at 7:49 AM, William A Rowe Jr  wrote:
> FULL STOP.

Really, NOW, simply don't talk to each other here (this way at least,
but anyway is fine too since it seems hopeless).

You are able to block each other on your respective networks, well,
keep reading your logs for bounced emails if it pleases you, but this
list (or any @a.o one) is definitively not an loop-hole!

Re: Status for 2.4.20

[William A Rowe Jr]

FULL STOP.

The next person to demand the last word of this thread will be iptables
deleted
from existence at a.o.  Can you all appreciate that ~2000 people have to
read
all of your pissing contests?  This is simply not acceptable.

Be done with it.

Re: Status for 2.4.20

[Noel Butler]

your short memory returns again, thank you, as that terminates any and 
all prior agreements we had about (not) responding to each other and 
your diatribe, the flood gates have now opened.


But as for this post, so it seems I did, I probably stopped reading half 
way, my care factor isnt all that high



On 29/03/2016 18:47, Reindl Harald wrote:


you did



--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: Status for 2.4.20

[Reindl Harald]

Am 29.03.2016 um 09:37 schrieb Noel Butler:

On 29/03/2016 01:06, William A Rowe Jr wrote:

@Everyone on this thread - keep it civil.
On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler <noel.but...@ausics.net
<mailto:noel.but...@ausics.net>> wrote:

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler
<noel.but...@ausics.net <mailto:noel.but...@ausics.net>> wrote:

as stated previously, this shit will happen when certain
people push with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched
by any pending release, so lets get house in order  S T A
B L E , then worry about releases, jesus christ, we are
not ubuntu or redhat with set programs to release every 3
or 6 months regardless if shit is ready or not.


It sounds like you're making drama where there is none.

sounds like you only look at this from one perspective, and thats
not of the users, especially, the larger users.


Going by this, I've not seen some posts, Bills reply makes it appear I
said the above, which I didnt


you did

 Weitergeleitete Nachricht 
Betreff: Re: Status for 2.4.20
Datum: Wed, 23 Mar 2016 21:58:18 +1000
Von: Noel Butler <noel.but...@ausics.net>
Antwort an: dev@httpd.apache.org
An: dev@httpd.apache.org

as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any pending
release, so lets get house in order S T A B L E , then worry about
releases, jesus christ, we are not ubuntu or redhat with set programs to
release every 3 or 6 months regardless if shit is ready or not.


flame away... IDGAF

 Weitergeleitete Nachricht ----
Betreff: Re: Status for 2.4.20
Datum: Sat, 26 Mar 2016 13:13:33 +1000
Von: Noel Butler <noel.but...@ausics.net>
Antwort an: dev@httpd.apache.org
An: dev@httpd.apache.org

On 25/03/2016 19:52, Graham Leggett wrote:
> It sounds like you're making drama where there is none.

sounds like you only look at this from one perspective, and thats not of 
the users, especially, the larger users.




signature.asc
Description: OpenPGP digital signature

Re: Status for 2.4.20

[Noel Butler]

On 29/03/2016 01:06, William A Rowe Jr wrote:

> @Everyone on this thread - keep it civil. 
> 
> On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler  wrote:
> On 25/03/2016 19:52, Graham Leggett wrote:
> On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:
> 
> as stated previously, this shit will happen when certain people push with a 
> release often mentality
> 
> AFAIK there is *ZERO* critical exploit bugs to be patched by any pending 
> release, so lets get house in order  S T A B L E , then worry about releases, 
> jesus christ, we are not ubuntu or redhat with set programs to release every 
> 3 or 6 months regardless if shit is ready or not. 
> It sounds like you're making drama where there is none.
 sounds like you only look at this from one perspective, and thats not
of the users, especially, the larger users. 

Precisely the point.  If httpd were commercial software, there would
only be 
one perspective, that of the largest users with fairly static
deployments that 
demand very small deltas - those that ensure few if any regressions. 
Smaller  
or more nimble users who need the most recent features are neglected in
that 
scenario. 

Instead httpd does not operate as commercial software, it is open
source. 
When it breaks, you get to keep (and patch) all the pieces.  That's the
origin 
story of this software and our continued model for success.  No amount
of 
pleas that "it shouldn't be that way" are going to change the mindset of
the 
project participants.  Please remember you are a guest on this list. 

When we decided during 1.3.x that things were so shaky (third party
module 
recompilation was frequently necessary during the early 1.3.0-1.3.14
versions) 
that we could do better for user communities. 

Therefore, when we released 2.0 as GA, we declared the ABI stable, and 
proceeded on ABI and API breaking work on a 2.1-dev trunk branch.  We
all 
agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we
believed 
that branch was ready to be ABI-stable.  That model continues to this
day, 
breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility

on the 2.4.x branch.  There were contentious discussions that led us to
this 
model, but it was driven by competing interests by the developers of
this 
project, who are also users --- as opposed to external "demands". 

We will seek to continue to release early and often, and one of our
current 
faults is that we haven't been releasing 2.5-dev often enough to engage
users 
in the next release series, but pouring most of our energy into wedging
these 
changes back into the 2.4.x branch.  But unlike commercial software and 
many OSS projects, we don't declare 2.4.0 to be "feature complete", and 
we continue to improve it in straightforward ways throughout the 2.4
lifetime. 

If you want to package a stable "product", you can follow the RedHat and

others' model.  Just to take that single example, httpd 2.4.3 is the
released 
flavor by RedHat.  They go to the extra effort to backport fixes-only
and plan 
to support that version for some 10 years or so.  That is why many
larger 
users choose to stick with something like RHEL or CentOS or similar 
distributions which are feature-frozen and much more stable than an
active 
product undergoing constant enhancement. 

Just to wrap up another tl;dr post... others offered you a different
option, 
skip those versions which are too "experimental" for your tastes, and
wait 
for bugs to shake out.  We assert that 2.4.newest is the best available 
version, but in such a large, modular and flexible project, it's
impossible 
to assure that a change set (release) will be an improvement for each
and 
every use case. 

Use the version that is most appropriate to your use case, and seek a  
commercial product if you expect the sort of stasis that your protest 
appears to seek. 

Going by this, I've not seen some posts, Bills reply makes it appear I
said the above, which I didnt, but I'll leave it as I think this thread
has run its course anyway, I've put my comments forward on behalf of
myself and many admins, I accept you only see this as one opinion since
they are not posting here, next time it comes up, I'll put a call on the
other lists for every single one of them to sub to this list and put
their thoughts forward :) 

-- 

If you have the urge to reply to all rather than reply to list, 
you
best first read  http://members.ausics.net/qwerty/

 

Re: Status for 2.4.20

[Stefan Eissing]

+1

Thanks!

> Am 28.03.2016 um 17:06 schrieb William A Rowe Jr :
> 
> @Everyone on this thread - keep it civil.
> 
>> On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler  wrote:
>>> On 25/03/2016 19:52, Graham Leggett wrote:
>>> On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:
>>> 
 as stated previously, this shit will happen when certain people push with 
 a release often mentality
 
 AFAIK there is *ZERO* critical exploit bugs to be patched by any pending 
 release, so lets get house in order  S T A B L E , then worry about 
 releases, jesus christ, we are not ubuntu or redhat with set programs to 
 release every 3 or 6 months regardless if shit is ready or not…..
>>> 
>>> It sounds like you’re making drama where there is none.
>> 
>> sounds like you only look at this from one perspective, and thats not of the 
>> users, especially, the larger users.
>  
> Precisely the point.  If httpd were commercial software, there would only be
> one perspective, that of the largest users with fairly static deployments that
> demand very small deltas - those that ensure few if any regressions.  Smaller 
> or more nimble users who need the most recent features are neglected in that
> scenario.
> 
> Instead httpd does not operate as commercial software, it is open source.
> When it breaks, you get to keep (and patch) all the pieces.  That's the origin
> story of this software and our continued model for success.  No amount of
> pleas that "it shouldn't be that way" are going to change the mindset of the
> project participants.  Please remember you are a guest on this list.
> 
> When we decided during 1.3.x that things were so shaky (third party module
> recompilation was frequently necessary during the early 1.3.0-1.3.14 versions)
> that we could do better for user communities.
> 
> Therefore, when we released 2.0 as GA, we declared the ABI stable, and
> proceeded on ABI and API breaking work on a 2.1-dev trunk branch.  We all
> agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed
> that branch was ready to be ABI-stable.  That model continues to this day,
> breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility
> on the 2.4.x branch.  There were contentious discussions that led us to this
> model, but it was driven by competing interests by the developers of this
> project, who are also users --- as opposed to external "demands".
> 
> We will seek to continue to release early and often, and one of our current
> faults is that we haven't been releasing 2.5-dev often enough to engage users
> in the next release series, but pouring most of our energy into wedging these
> changes back into the 2.4.x branch.  But unlike commercial software and
> many OSS projects, we don't declare 2.4.0 to be "feature complete", and
> we continue to improve it in straightforward ways throughout the 2.4 lifetime.
> 
> If you want to package a stable "product", you can follow the RedHat and
> others' model.  Just to take that single example, httpd 2.4.3 is the released
> flavor by RedHat.  They go to the extra effort to backport fixes-only and plan
> to support that version for some 10 years or so.  That is why many larger
> users choose to stick with something like RHEL or CentOS or similar
> distributions which are feature-frozen and much more stable than an active
> product undergoing constant enhancement.
> 
> Just to wrap up another tl;dr post... others offered you a different option,
> skip those versions which are too "experimental" for your tastes, and wait
> for bugs to shake out.  We assert that 2.4.newest is the best available
> version, but in such a large, modular and flexible project, it's impossible
> to assure that a change set (release) will be an improvement for each and
> every use case.
> 
> Use the version that is most appropriate to your use case, and seek a 
> commercial product if you expect the sort of stasis that your protest
> appears to seek.
> 
> 

Re: Status for 2.4.20

[William A Rowe Jr]

@Everyone on this thread - keep it civil.

On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler 
wrote:

> On 25/03/2016 19:52, Graham Leggett wrote:
>
>> On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:
>>
>> as stated previously, this shit will happen when certain people push with
>>> a release often mentality
>>>
>>> AFAIK there is *ZERO* critical exploit bugs to be patched by any pending
>>> release, so lets get house in order  S T A B L E , then worry about
>>> releases, jesus christ, we are not ubuntu or redhat with set programs to
>>> release every 3 or 6 months regardless if shit is ready or not…..
>>>
>>
>> It sounds like you’re making drama where there is none.
>>
>
> sounds like you only look at this from one perspective, and thats not of
> the users, especially, the larger users.


Precisely the point.  If httpd were commercial software, there would only be
one perspective, that of the largest users with fairly static deployments
that
demand very small deltas - those that ensure few if any regressions.
Smaller
or more nimble users who need the most recent features are neglected in that
scenario.

Instead httpd does not operate as commercial software, it is open source.
When it breaks, you get to keep (and patch) all the pieces.  That's the
origin
story of this software and our continued model for success.  No amount of
pleas that "it shouldn't be that way" are going to change the mindset of the
project participants.  Please remember you are a guest on this list.

When we decided during 1.3.x that things were so shaky (third party module
recompilation was frequently necessary during the early 1.3.0-1.3.14
versions)
that we could do better for user communities.

Therefore, when we released 2.0 as GA, we declared the ABI stable, and
proceeded on ABI and API breaking work on a 2.1-dev trunk branch.  We all
agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed
that branch was ready to be ABI-stable.  That model continues to this day,
breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility
on the 2.4.x branch.  There were contentious discussions that led us to this
model, but it was driven by competing interests by the developers of this
project, who are also users --- as opposed to external "demands".

We will seek to continue to release early and often, and one of our current
faults is that we haven't been releasing 2.5-dev often enough to engage
users
in the next release series, but pouring most of our energy into wedging
these
changes back into the 2.4.x branch.  But unlike commercial software and
many OSS projects, we don't declare 2.4.0 to be "feature complete", and
we continue to improve it in straightforward ways throughout the 2.4
lifetime.

If you want to package a stable "product", you can follow the RedHat and
others' model.  Just to take that single example, httpd 2.4.3 is the
released
flavor by RedHat.  They go to the extra effort to backport fixes-only and
plan
to support that version for some 10 years or so.  That is why many larger
users choose to stick with something like RHEL or CentOS or similar
distributions which are feature-frozen and much more stable than an active
product undergoing constant enhancement.

Just to wrap up another tl;dr post... others offered you a different option,
skip those versions which are too "experimental" for your tastes, and wait
for bugs to shake out.  We assert that 2.4.newest is the best available
version, but in such a large, modular and flexible project, it's impossible
to assure that a change set (release) will be an improvement for each and
every use case.

Use the version that is most appropriate to your use case, and seek a
commercial product if you expect the sort of stasis that your protest
appears to seek.

Re: Status for 2.4.20

[Noel Butler]

On 26/03/2016 22:54, Reindl Harald wrote:


*yawn*


grow up!

especially with your off-list hate-mails while block responses



off-list hate mails? The message was pretty clear you emailed me asking 
me never to reply to any of your posts some time ago, I emailed you 
reminding you that works both fscking ways and if you didnt like that 
hell will be unleashed upon you.



also, the DNSBL blacklisting on you for your antics of past 2+ years or 
so still stands given what I've witnessed even in recent times. If you 
are going to be abusive, and  blackmailing people, you have to live with 
reactions to your actions, it is only appropriate a DNSBL "tell" people 
why a host is blocked, just proudly doing my job :)


if you were not a complete arsehole, none of those list moderations, 
bannings and so on would have occurred, but seems like you will never 
change, consider this the last time i reply to you on this list, and 
thank you for re-justifying the DNSBL listing.


happy easter

--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: Status for 2.4.20

[Daniel Ruggeri]

On 3/23/2016 7:27 AM, Jim Jagielski wrote:
> Release Often is hardly a Bad Thing, at least IMHO. When the
> time is right for a release, then we release. It seemed a
> good time, again IMHO.

Kinda late to the party, but shouldn't what's committed to a stable
branch _always_ be ready to release?



Just my .02 on the side conversation. As a sysadmin, I have no strong
preference for release often versus release seldom... just so long as
what is released is stable and won't break my stuff.
At $dayjob where I have to answer to regulatory and audit authorities,
there have been plenty of releases of various software platforms that I
have chosen not to pursue because they don't address anything I need to
worry about. No harm done.

So, my stance as a sysadmin (and probably a fairly common stance, I'd
guess) can be summarized as:
If there's a bug fix for a problem I'm seeing, I'd really like the
release sooner rather than later. On the other hand, if there's a
security fix, I need it released immediately. On yet another hand
(because it seems I have three), if the release has nothing I care
about... then I don't care.
But whatever happens, don't break my configs :-)



As an even further side note... after following this dev list
(community) as long as I have, I'd happily put an httpd 2.4.nightly
against just about any other released software. I can't think of a
single case where something got *committed* to 2.4 that would break my
configs let alone something that got formally released. Indeed, the few
thousand httpd servers I run haven't been harmed by a release in all of
my time as an admin (1.3, 2.0 and 2.4 alike). Our release process is,
indeed, pretty damn good. So whether we release often or release seldom,
we can at least hold our head high while we do it.

-- 
Daniel Ruggeri

Re: Status for 2.4.20

[Reindl Harald]

Am 26.03.2016 um 04:44 schrieb Noel Butler:

On 26/03/2016 13:32, Reindl Harald wrote:

Am 26.03.2016 um 04:13 schrieb Noel Butler:

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:


as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any
pending release, so lets get house in order  S T A B L E , then worry
about releases, jesus christ, we are not ubuntu or redhat with set
programs to release every 3 or 6 months regardless if shit is ready
or not…..


It sounds like you’re making drama where there is none.


sounds like you only look at this from one perspective, and thats not of
the users, especially, the larger users.


if it has no relevant bugfixes for you - just don't upgrade - so what
why should others wait for probably relevant fixes longer just because
you are annoyed by an update nobody is forcing you to install?


*yawn*


grow up!

especially with your off-list hate-mails while block responses



signature.asc
Description: OpenPGP digital signature

Re: Status for 2.4.20

[Noel Butler]

On 26/03/2016 13:32, Reindl Harald wrote:

Am 26.03.2016 um 04:13 schrieb Noel Butler:

On 25/03/2016 19:52, Graham Leggett wrote:
On 23 Mar 2016, at 1:58 PM, Noel Butler  
wrote:



as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any
pending release, so lets get house in order  S T A B L E , then 
worry

about releases, jesus christ, we are not ubuntu or redhat with set
programs to release every 3 or 6 months regardless if shit is ready
or not…..


It sounds like you’re making drama where there is none.


sounds like you only look at this from one perspective, and thats not 
of

the users, especially, the larger users.


if it has no relevant bugfixes for you - just don't upgrade - so what
why should others wait for probably relevant fixes longer just because
you are annoyed by an update nobody is forcing you to install?



*yawn*

--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: Status for 2.4.20

[Reindl Harald]

Am 26.03.2016 um 04:13 schrieb Noel Butler:

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:


as stated previously, this shit will happen when certain people push
with a release often mentality

AFAIK there is *ZERO* critical exploit bugs to be patched by any
pending release, so lets get house in order  S T A B L E , then worry
about releases, jesus christ, we are not ubuntu or redhat with set
programs to release every 3 or 6 months regardless if shit is ready
or not…..


It sounds like you’re making drama where there is none.


sounds like you only look at this from one perspective, and thats not of
the users, especially, the larger users.


if it has no relevant bugfixes for you - just don't upgrade - so what
why should others wait for probably relevant fixes longer just because 
you are annoyed by an update nobody is forcing you to install?





signature.asc
Description: OpenPGP digital signature

Re: Status for 2.4.20

[Noel Butler]

On 25/03/2016 19:52, Graham Leggett wrote:

On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:

as stated previously, this shit will happen when certain people push 
with a release often mentality


AFAIK there is *ZERO* critical exploit bugs to be patched by any 
pending release, so lets get house in order  S T A B L E , then worry 
about releases, jesus christ, we are not ubuntu or redhat with set 
programs to release every 3 or 6 months regardless if shit is ready or 
not…..


It sounds like you’re making drama where there is none.


sounds like you only look at this from one perspective, and thats not of 
the users, especially, the larger users.




--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: Status for 2.4.20

[Graham Leggett]

On 23 Mar 2016, at 1:58 PM, Noel Butler  wrote:

> as stated previously, this shit will happen when certain people push with a 
> release often mentality
> 
> AFAIK there is *ZERO* critical exploit bugs to be patched by any pending 
> release, so lets get house in order  S T A B L E , then worry about releases, 
> jesus christ, we are not ubuntu or redhat with set programs to release every 
> 3 or 6 months regardless if shit is ready or not…..

It sounds like you’re making drama where there is none.

We have a release process designed to catch problems before they reach the 
public. That release process caught a problem, and that problem is being dealt 
with as per that release process. The system is working, nothing to see here.

Regards,
Graham
—

Re: Status for 2.4.20

[Noel Butler]

On 23/03/2016 22:27, Jim Jagielski wrote:



I see your point and have no intent or desire to flame.

Release Often is hardly a Bad Thing, at least IMHO. When the
time is right for a release, then we release. It seemed a
good time, again IMHO.

My opinion that "this shit will happen" when, despite lots of
notice of intent to tag, and reminders to test, etc.. people
simply DON'T, wait for the test tarball, find breakage, and
then apply major restructure/refactor "at the last minute".

Sure, stuff that like occasionally will happen, and it is,
after all, why we create test tarballs and call for a vote.
But when it becomes the rule instead of the exception, then
we have an issue w/ the process and the workflow.

Frequent release, IMHO, are an indication of health and
project vitality. When Apache httpd is suffering from the



You also need to look at it from the side of system admins, not just as 
coder.


Many admins see frequent releases as something that's bug riddled

You don't hear them saying the same about other software, eg: postfix, 
which releases not so frequently (though puts new things in the unstable 
branch)


Dovecot is a great example of release often with F-ups, and it doesn't 
take much to see that it has problems which need addressing soon after 
each release, phpmyadmin releases often, so often, even Marc got sick of 
it and decided there would be minimum monthly updates, instead of 
bi-weekly updates, I know admins running phpmyadmin thats over a year 
old because they got sick of upgrading every few days.


So it works both ways, releasing every 5 or 6 months shows an active 
_stable_ project, evervy month or two and it raises alarms.


But thats just my opinion which does tend to be a general consensus on 
many system admin lists/irc chans.



--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Thu, Mar 24, 2016 at 11:40 AM, Jan Ehrhardt  wrote:

> William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17
> -0500):
> >>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html
> >
> >It's been a *long* time, and I know it hadn't been that well maintained
> >for non-Linux (non-BSD) target architectures.
>
> On the contrary: Windows support for PHP has made a big jump. The release
> master of PHP7 is even a Microsoft employee.
>

Excellent!

>> Even in the 32-bits PHP 7 there are some:
> >>
> >>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html
> >
> >With a bit of luck - many of these are resolved by simply jumping up to
> >Visual Studio 2015 (and removing any number of win32-specific bandaids
> >that covered some warts in the earlier stdc lib)?
>
> Read carefully: these are the results when compiling with VC14 == VS2015.
> This is the way the official PHP7 binaries are built.
>

And in fairness, not every "conversion from 'size_t' to 'unsigned int'"
error is
actually a lurking bug.  If you know the memory allocation can't exceed some
fixed size (e.g. passed as an httpd header value that already enjoys
truncation
or rejection much earlier in the process), then that flag would generally
mean
nothing.

It's a long process to get such things 100% correct, we have a few defects
lingering in httpd 2.4 release branch today - some due to binary ABI
restrictions.
My entire point is that VC14 makes such a thing possible, where it really
wasn't possible while Microsoft was ignoring POSIX in many places.

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17
-0500):
>> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html
>
>It's been a *long* time, and I know it hadn't been that well maintained
>for non-Linux (non-BSD) target architectures.

On the contrary: Windows support for PHP has made a big jump. The release
master of PHP7 is even a Microsoft employee.

>> Even in the 32-bits PHP 7 there are some:
>>
>> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html
>
>With a bit of luck - many of these are resolved by simply jumping up to
>Visual Studio 2015 (and removing any number of win32-specific bandaids
>that covered some warts in the earlier stdc lib)?

Read carefully: these are the results when compiling with VC14 == VS2015.
This is the way the official PHP7 binaries are built.

Jan

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Yann Ylavic]

On Thu, Mar 24, 2016 at 3:40 PM, William A Rowe Jr  wrote:
> On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavic  wrote:
>>
>> Not to talk about they very personal conception of sizeof(long) on
>> 64bit systems...
>
> You might be too young to remember when pointers had little to
> no relation to integer registers on many cpu architectures :)

I'm afraid not :(
I wasn't talking about pointers here, though, but I agree that numeric
types have never been something consistent accross platforms either.

Simply now that char/short/int/long types could have had (finally!)
there own size, and a common and consistent agreement on, for all/most
modern systems... it failed.

They surely had good reasons to do so, though it might just have
moved/postponed the issues (to portable coders, at least). But after
all, let's all use the APR! :)

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavic  wrote:

> >> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or
> >> variable may be unsafe. Consider using vsnprintf_s instead. To disable
> >> deprecation, use _CRT_SECURE_NO_WARNINGS.
>
> [sarcasm]
> Microsoft being unable to provide a safe vsnprintf() in the first
> place and now warning every user is kind of ironic.
>

Microsoft claims that all the non-MS foo_s variants that have buffer
targets as defined by POSIX are insecure, and offer foo_s variants.
We have apr's safe strncpy etc, so it's not like we didn't agree -
at least for some cases.

They are free to make any claim they like, but they offered an out...
from these warnings ... -D_CRT_SECURE_NO_DEPRECATE


> Not to talk about they very personal conception of sizeof(long) on
> 64bit systems...
>

You might be too young to remember when pointers had little to
no relation to integer registers on many cpu architectures :)

[/sarcasm]
>
> Not a very constructive comment, I agree :)
>

:)

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Yann Ylavic]

>> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or
>> variable may be unsafe. Consider using vsnprintf_s instead. To disable
>> deprecation, use _CRT_SECURE_NO_WARNINGS.

[sarcasm]
Microsoft being unable to provide a safe vsnprintf() in the first
place and now warning every user is kind of ironic.

Not to talk about they very personal conception of sizeof(long) on
64bit systems...
[/sarcasm]

Not a very constructive comment, I agree :)

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Thu, Mar 24, 2016 at 8:49 AM, Jan Ehrhardt  wrote:

> William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45
> -0500):
> >Precisely, Jan.  We don't know where these truncation errors lead - do
> they
> >portentially open security holes?  They cetainly interefere with serving
> >huge resources such as .iso images.
> >
> >When I first tripped over this, I breifly pondered putting together a
> >patch.  PHP, httpd (through apr) dealt with all this long ago.
>
> Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There
> are loads of 'possible loss of data' warnings. See for yourself:
>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html


It's been a *long* time, and I know it hadn't been that well maintained
for non-Linux (non-BSD) target architectures.


> Even in the 32-bits PHP 7 there are some:
>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html


With a bit of luck - many of these are resolved by simply jumping up to
Visual Studio 2015 (and removing any number of win32-specific bandaids
that covered some warts in the earlier stdc lib)?

Remaining errors likely still need fixing.  That sizeof(int) == sizeof(void
*)
assumption from 64ILP architectures is *not* part of the spec.  We have
64ILP (int == long == void*), 64LP (long == void* != int) as well as
64P (long == int != void*) and each of these are valid architectures.

The various types such as ptrdiff_t that POSIX exposes *should* resolve
these all when the correct types are chosen, and that is now true with
MSVC 14 on Windows as well.  It just becomes a matter of using the
true and correct type for various operations.

Cheers,

Bill

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45
-0500):
>Precisely, Jan.  We don't know where these truncation errors lead - do they
>portentially open security holes?  They cetainly interefere with serving
>huge resources such as .iso images.
>
>When I first tripped over this, I breifly pondered putting together a
>patch.  PHP, httpd (through apr) dealt with all this long ago.

Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There
are loads of 'possible loss of data' warnings. See for yourself:
http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html

Even in the 32-bits PHP 7 there are some:
http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html

Jan

mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Mar 23, 2016 22:19, "Jan Ehrhardt"  wrote:
>
> William A Rowe Jr in gmane.comp.apache.devel (Wed, 23 Mar 2016 08:00:19
> -0500):
> >On Wed, Mar 23, 2016 at 7:42 AM, William A Rowe Jr 
> >wrote:
> >
> >> Again, a C89 regression breaking the candidate, but in an experimental
> >> module that we don't promise will always build.  nghttp2 is filled
with C99
> >> code, AIUI - due to bad decisions about basic C types - that library
can
> >> only build.
> >>
> >Whoops, answering too quickly...
> >
> >that library can only build *correctly* under the latest MSVC 14 (aka
> >Studio 2015) when you are compiling for 64-bits on Windows (not an issue
> >with 32 bit builds).
>
> How do you define 'correctly'? nghttp2 (git head) builds with only a
> single warning on VC14 x86:
>
> c:\php-sdk\prebuilt\nghttp2\lib\nghttp2_session.c(6767) : warning C4715:
> 'nghttp2_session_get_remote_settings': not all control paths return a
> value
>
> VC11 x86 and VC9 x86 builds of nghttp2 give a couple of extra warnings:
>
> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or
> variable may be unsafe. Consider using vsnprintf_s instead. To disable
> deprecation, use _CRT_SECURE_NO_WARNINGS.
>
> All x64 builds issue many more warnings:
>
> cl -nologo -MD  -W3 -Z7 -DBUILDING_NGHTTP2 -I./includes -Dssize_t=long
> -D_U_="" -FoMSVC_obj /r_nghttp2_session.obj -c nghttp2_session.c
> nghttp2_session.c
> nghttp2_session.c(5092): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5122): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5477): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5704): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5888): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5952): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(6082): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(6191): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data

Precisely, Jan.  We don't know where these truncation errors lead - do they
portentially open security holes?  They cetainly interefere with serving
huge resources such as .iso images.

When I first tripped over this, I breifly pondered putting together a
patch.  PHP, httpd (through apr) dealt with all this long ago.

But nghttp2 is a modern C99/POSIX app, why ask the author to code around
Win32-isms, now that MS finally got these right with the VC14 release?

Re: Status for 2.4.20

[Jim Jagielski]

Tell you what. Let's delay for 1 week and I'll take up a T
on Monday April 4th.

Re: Status for 2.4.20

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Wed, 23 Mar 2016 08:00:19
-0500):
>On Wed, Mar 23, 2016 at 7:42 AM, William A Rowe Jr 
>wrote:
>
>> Again, a C89 regression breaking the candidate, but in an experimental
>> module that we don't promise will always build.  nghttp2 is filled with C99
>> code, AIUI - due to bad decisions about basic C types - that library can
>> only build.
>>
>Whoops, answering too quickly...
>
>that library can only build *correctly* under the latest MSVC 14 (aka
>Studio 2015) when you are compiling for 64-bits on Windows (not an issue
>with 32 bit builds).

How do you define 'correctly'? nghttp2 (git head) builds with only a
single warning on VC14 x86:

c:\php-sdk\prebuilt\nghttp2\lib\nghttp2_session.c(6767) : warning C4715:
'nghttp2_session_get_remote_settings': not all control paths return a
value

VC11 x86 and VC9 x86 builds of nghttp2 give a couple of extra warnings:

nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or
variable may be unsafe. Consider using vsnprintf_s instead. To disable
deprecation, use _CRT_SECURE_NO_WARNINGS.

All x64 builds issue many more warnings:

cl -nologo -MD  -W3 -Z7 -DBUILDING_NGHTTP2 -I./includes -Dssize_t=long
-D_U_="" -FoMSVC_obj /r_nghttp2_session.obj -c nghttp2_session.c
nghttp2_session.c
nghttp2_session.c(5092): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data
nghttp2_session.c(5122): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data
nghttp2_session.c(5477): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data
nghttp2_session.c(5704): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data
nghttp2_session.c(5888): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data
nghttp2_session.c(5952): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data
nghttp2_session.c(6082): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data
nghttp2_session.c(6191): warning C4244: 'return': conversion from
'__int64' to 'long', possible loss of data

Jan

Re: Status for 2.4.20

[William A Rowe Jr]

On Wed, Mar 23, 2016 at 7:42 AM, William A Rowe Jr 
wrote:

> > branches/2.4.x/modules/http2/h2_filter.c
>
> Again, a C89 regression breaking the candidate, but in an experimental
> module that we don't promise will always build.  nghttp2 is filled with C99
> code, AIUI - due to bad decisions about basic C types - that library can
> only build.
>
Whoops, answering too quickly...

that library can only build *correctly* under the latest MSVC 14 (aka
Studio 2015)
when you are compiling for 64-bits on Windows (not an issue with 32 bit
builds).

In the past, size_t/ssize_t/ptrdiff_t and other alignment primitives failed
to
correspond to the width of their defined domain (size reflects memory, ergo
thes must be the same size, bitwise, as a void*).  This showed up very
egregiously in nghttp2 which (fairly) demands that the POSIX types reflect
their definitions.

MS finally is catching up to POSIX with their Studio 2015 product release.
So the antique .dsp is something of a red herring, you probably don't want
to ever run an nghttp2 app or library compiled against VC98, if building to
64-bits.  It is hardly a fully-conformant C99 compiler, but it comes a whole
lot closer than previous attempts.

Re: Status for 2.4.20

[William A Rowe Jr]

On Mar 23, 2016 6:23 AM, "Steffen"  wrote:
>
> Just did a export;
>
> Diff with the vote 2.4.19 one:
>
> branches/2.4.x/modules/cache/mod_socache_shmcb.c

Correct.  I'm not claiming this is win32-specific, it only happens to show
up on that and other edge cases.

> branches/2.4.x/modules/http2/h2_filter.c

Again, a C89 regression breaking the candidate, but in an experimental
module that we don't promise will always build.  nghttp2 is filled with C99
code, AIUI - due to bad decisions about basic C types - that library can
only build.

> branches/2.4.x/modules/http2/mod_http2.dsp

Looking good.

> For remove mod_lbmethod-rr:
> branches/2.4.x/Makefile.win
> branches/2.4.x/Readme.cmake
> branches/2.4.x/Apache.dsw
> branches/2.4.x/Apache-apr2.dsw

This may be reverted of course, if someone believes we should persist this
non-compileable example.

> And a bunch of .dep and mak files added

This simplifies the process for users who don't want to go through a manual
process of converting archaic project files to Windows.

This is the same structure as in every httpd 2.2 tarball.

But an explanation is in order... I haven't directly used these build files
-myself- for creating anything other than ASF binaries in over a decade.
They were not suited for building component-by-component, only for building
the whole shooting match at once.  I've been building each component (pcre,
expat, zlib, apr etc etc) for forever now.

The .mak/.dep files and Makefile.win (which invokes these) supports only
the srclib/ subcomponents structure.  You'll find Windows .mak/.dep files
in those apr source projects as well.

So this change neither breaks nor fixes - it is an alternative to a manual
conversion - it merely simplifies building on Windows - until cmake builds
are considered the replacement.  The addition of these to the svn, rather
than only a win32 source tarball, has a lengthy discussion and rational in
dev@ archive already.

But I have no preference as a user, myself - my entire interest lies in
cmake.

Re: Status for 2.4.20

[Jeff Trawick]

On Wed, Mar 23, 2016 at 6:56 AM, Jim Jagielski  wrote:

> Let's see: I recalled the vote for 2.4.19 because of a
> single issue, basically related to a missing few lines in
> a file which prevented building on Win. Nice, easy, simple
> fix.
>
> Now it appears that a slew of "fixes" related to Win have
> been applied which, according to some, makes the whole build-
> on-Win situation much much worse.
>
> Now I have no idea what the status of HEAD for 2.4 is and,
> as a result, we are delaying the T and eventual release of
> 2.4.19/20. All because a 4-line fix turned into a master-refactor
> at the last minute.
>
>
Slightly off-topic: 2.4.x HEAD builds fine and serves pages with VS 2012
using the cmake build.  (I was initially sidetracked by the need for a
higher level of nghttp2 to fix their Win32 linkage problem in APIs we
didn't use last time I built on Windows, then by trunk build problems.)


I am tempted to revert 2.4 back...
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Status for 2.4.20

[Jim Jagielski]

> On Mar 23, 2016, at 7:58 AM, Noel Butler  wrote:
> 
> On 23/03/2016 20:56, Jim Jagielski wrote:
>> Let's see: I recalled the vote for 2.4.19 because of a
>> single issue, basically related to a missing few lines in
>> a file which prevented building on Win. Nice, easy, simple
>> fix.
>> Now it appears that a slew of "fixes" related to Win have
>> been applied which, according to some, makes the whole build-
>> on-Win situation much much worse.
>> Now I have no idea what the status of HEAD for 2.4 is and,
>> as a result, we are delaying the T and eventual release of
>> 2.4.19/20. All because a 4-line fix turned into a master-refactor
>> at the last minute.
>> I am tempted to revert 2.4 back...
> 
> 
> as stated previously, this shit will happen when certain people push with a 
> release often mentality
> 
> AFAIK there is *ZERO* critical exploit bugs to be patched by any pending 
> release, so lets get house in order  S T A B L E , then worry about releases, 
> jesus christ, we are not ubuntu or redhat with set programs to release every 
> 3 or 6 months regardless if shit is ready or not.
> 
> 
> flame away... IDGAF

I see your point and have no intent or desire to flame.

Release Often is hardly a Bad Thing, at least IMHO. When the
time is right for a release, then we release. It seemed a
good time, again IMHO.

My opinion that "this shit will happen" when, despite lots of
notice of intent to tag, and reminders to test, etc.. people
simply DON'T, wait for the test tarball, find breakage, and
then apply major restructure/refactor "at the last minute".

Sure, stuff that like occasionally will happen, and it is,
after all, why we create test tarballs and call for a vote.
But when it becomes the rule instead of the exception, then
we have an issue w/ the process and the workflow.

Frequent release, IMHO, are an indication of health and
project vitality. When Apache httpd is suffering from the
FUD of being old, slow, behind-the-times, lacking features
and capability, etc, I think showing our community that we
are actively working the code, adding features, fixing
bugs, making improvements, etc is a Good Thing.

Re: Status for 2.4.20

[Noel Butler]

On 23/03/2016 20:56, Jim Jagielski wrote:

Let's see: I recalled the vote for 2.4.19 because of a
single issue, basically related to a missing few lines in
a file which prevented building on Win. Nice, easy, simple
fix.

Now it appears that a slew of "fixes" related to Win have
been applied which, according to some, makes the whole build-
on-Win situation much much worse.

Now I have no idea what the status of HEAD for 2.4 is and,
as a result, we are delaying the T and eventual release of
2.4.19/20. All because a 4-line fix turned into a master-refactor
at the last minute.

I am tempted to revert 2.4 back...



as stated previously, this shit will happen when certain people push 
with a release often mentality


AFAIK there is *ZERO* critical exploit bugs to be patched by any pending 
release, so lets get house in order  S T A B L E , then worry about 
releases, jesus christ, we are not ubuntu or redhat with set programs to 
release every 3 or 6 months regardless if shit is ready or not.



flame away... IDGAF

--
If you have the urge to reply to all rather than reply to list, you best
first read  http://members.ausics.net/qwerty/

Re: Status for 2.4.20

[Yann Ylavic]

On Wed, Mar 23, 2016 at 12:22 PM, Steffen  wrote:
> Just did a export;
>
> Diff with the vote 2.4.19 one:
>
> branches/2.4.x/modules/cache/mod_socache_shmcb.c
> branches/2.4.x/modules/http2/h2_filter.c
> branches/2.4.x/modules/http2/mod_http2.dsp
>
> For remove mod_lbmethod-rr:
> branches/2.4.x/Makefile.win
> branches/2.4.x/Readme.cmake
> branches/2.4.x/Apache.dsw
> branches/2.4.x/Apache-apr2.dsw
>
> And a bunch of .dep and mak files added

Yes, so did it break (or fix) the Windows build?

Thanks,
Yann.

Re: Status for 2.4.20

[Steffen]

Just did a export;

Diff with the vote 2.4.19 one:

branches/2.4.x/modules/cache/mod_socache_shmcb.c
branches/2.4.x/modules/http2/h2_filter.c
branches/2.4.x/modules/http2/mod_http2.dsp

For remove mod_lbmethod-rr:
branches/2.4.x/Makefile.win
branches/2.4.x/Readme.cmake
branches/2.4.x/Apache.dsw
branches/2.4.x/Apache-apr2.dsw

And a bunch of .dep and mak files added




On Wednesday 23/03/2016 at 11:56, Jim Jagielski  wrote:

Let's see: I recalled the vote for 2.4.19 because of a
single issue, basically related to a missing few lines in
a file which prevented building on Win. Nice, easy, simple
fix.

Now it appears that a slew of "fixes" related to Win have
been applied which, according to some, makes the whole build-
on-Win situation much much worse.

Now I have no idea what the status of HEAD for 2.4 is and,
as a result, we are delaying the T and eventual release of
2.4.19/20. All because a 4-line fix turned into a master-refactor
at the last minute.

I am tempted to revert 2.4 back...

Re: Status for 2.4.20

[Stefan Eissing]

> Am 23.03.2016 um 11:56 schrieb Jim Jagielski :
> 
> Let's see: I recalled the vote for 2.4.19 because of a
> single issue, basically related to a missing few lines in
> a file which prevented building on Win. Nice, easy, simple
> fix.
> 
> Now it appears that a slew of "fixes" related to Win have
> been applied which, according to some, makes the whole build-
> on-Win situation much much worse.
> 
> Now I have no idea what the status of HEAD for 2.4 is and,
> as a result, we are delaying the T and eventual release of
> 2.4.19/20. All because a 4-line fix turned into a master-refactor
> at the last minute.
> 
> I am tempted to revert 2.4 back...

Sorry about missing the initial 4 lines. 

Being no Windows builder, but is the 2.4.19 + the missing 
lines not the same mechanism that we shipped in 2.4.18? 

If so, let's stick to it and defer any large-scale 
improvements to a later point.

Status for 2.4.20

[Jim Jagielski]

Let's see: I recalled the vote for 2.4.19 because of a
single issue, basically related to a missing few lines in
a file which prevented building on Win. Nice, easy, simple
fix.

Now it appears that a slew of "fixes" related to Win have
been applied which, according to some, makes the whole build-
on-Win situation much much worse.

Now I have no idea what the status of HEAD for 2.4 is and,
as a result, we are delaying the T and eventual release of
2.4.19/20. All because a 4-line fix turned into a master-refactor
at the last minute.

I am tempted to revert 2.4 back...