Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[William A Rowe Jr]

Let me counter with this... Rather than break the API every m.n release,
what if we roll on to 2.6 with no ABI breakage, or resolve with impumity
everything wrong in 3.0 with a firm commitment not to break it again till
4.0?

This might be the root problem of our trying to !is versioning semantics.


On Thu, Apr 19, 2018, 19:39 Daniel Ruggeri  wrote:

> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
>
>
> If we end up with API and feature freeze on branch 2.4, then we'd expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
>
>
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches and a
> bugfix applicable to all (or worse... a security fix that would dictate
> all should be released/disclosed at the same time).
>
> --
> Daniel Ruggeri
>
> On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> > I don't disagree with RC's entirely, or the mechanism you suggest, but
> > that isn't what I read as proposed.
> >
> > Our issue is that every httpd must be distinguished, we won't ship
> > four tarballs all claiming 2.4.34 (GA). Which one is the person
> > complaining about? Are we back to SHA signature of the source tarball
> > (that isn't even assuredly what they built the binary from?)
> >
> > We can decorate the rc in the versioning, but that isn't part of 2.4.x
> > API, unless we swap out the "-dev" string tag for an "-rc#" value.
> >
> > It is not reasonable to lock a branch for an indeterminate length of
> > time. Branching the RC into what becomes the final release, and making
> > it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> > might help discourage disruptive backports, but there is no suggestion
> > yet of what is acceptable, either on such a frozen main branch or rc
> > branch.
> >
> > In fact our policy reflects that two competing release candidates is
> > an entire valid and even expected situation, and any process that
> > further blocks this should be firmly rebuffed.
> >
> > As it reads so far the proposal is the way we do things, now
> > conserving subversion numbers as precious, if only to reenforce a
> > stake in the ground that version major and minor numbers are similarly
> > precious, (which they are not.)
> >
> > With the addition of freezing changes on 2.4.x branch for a time we
> > succeed in impeading progress towards version .next, while not
> > otherwise changing the status quo.
> >
> > What you suggest is yet another thing, based on forking the RC release
> > branch, and I haven't seen that accepted by the committee yet.
> >
> > On Thu, Apr 19, 2018, 16:43 David Zuelke  > > wrote:
> >
> > The main difference is that you have a release branch in which fixes
> > to bugs or regressions found during 2.4.x RCs can be made, while work
> > on 2.4.(x+1) can continue in the main 2.4 branch.
> >
> > Another benefit is that people who do automated builds (e.g. me) can
> > grep for "RC" in the version number and have it fetch from
> > https://dist.apache.org/repos/dist/dev/httpd/ instead.
> >
> > The changelogs are more readable as well, because it's obvious which
> > intermediary RC releases belong together. If you look at
> > https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> > indication that e.g. 2.4.31 was never released.
> >
> >
> > On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
> > > wrote:
> > > What possible improvement occurs if there is no branch discipline
> > > on 2.4.x development? We just echoed effectively your proposal,
> > > using numbers rather than RC designations, and still .33 has this
> > > host of issues. With no release since .29, the branch was in this
> > > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > > .31 didn't result in a better .32, and even the final .33 had
> > its own
> > > issues.
> > >
> > > This would have been precisely the same outcome between RC1
> > > and RC4, if the project doesn't keep the branch stable for even the
> > > week or months required to craft a successful release, and if that
> > > occurs on 2.4.x branch, that is an interruption of effort towards
> > > release n+1, frustrating contributors.
> > >
> > > Note 

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[Daniel Ruggeri]

I'm not sure where in the conversation to add this, but I do want to
point out a mechanical concern.


If we end up with API and feature freeze on branch 2.4, then we'd expect
to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
branch) can't get a feature or the next great thing because of a
required API incompatible change. We would then kick out 2.8, 2.10 and
so on and so forth. This seems like it would satisfy both the
keep-the-stuff-stable as well as the give-users-new-stuff "sides".


Mechanically, this can become tiresome for a volunteer as we work
through the STATUS ceremony for each of the branches. I remember that
being less than enjoyable when 2.0, 2.2 and 2.4 were all release
branches. I'm fearful of a future where we may have five branches and a
bugfix applicable to all (or worse... a security fix that would dictate
all should be released/disclosed at the same time).

-- 
Daniel Ruggeri

On 4/19/2018 7:17 PM, William A Rowe Jr wrote:
> I don't disagree with RC's entirely, or the mechanism you suggest, but
> that isn't what I read as proposed.
>
> Our issue is that every httpd must be distinguished, we won't ship
> four tarballs all claiming 2.4.34 (GA). Which one is the person
> complaining about? Are we back to SHA signature of the source tarball
> (that isn't even assuredly what they built the binary from?)
>
> We can decorate the rc in the versioning, but that isn't part of 2.4.x
> API, unless we swap out the "-dev" string tag for an "-rc#" value.
>
> It is not reasonable to lock a branch for an indeterminate length of
> time. Branching the RC into what becomes the final release, and making
> it painful to backport first to 2.4.x and finally 2.4.n-rc branch
> might help discourage disruptive backports, but there is no suggestion
> yet of what is acceptable, either on such a frozen main branch or rc
> branch.
>
> In fact our policy reflects that two competing release candidates is
> an entire valid and even expected situation, and any process that
> further blocks this should be firmly rebuffed.
>
> As it reads so far the proposal is the way we do things, now
> conserving subversion numbers as precious, if only to reenforce a
> stake in the ground that version major and minor numbers are similarly
> precious, (which they are not.)
>
> With the addition of freezing changes on 2.4.x branch for a time we
> succeed in impeading progress towards version .next, while not
> otherwise changing the status quo.
>
> What you suggest is yet another thing, based on forking the RC release
> branch, and I haven't seen that accepted by the committee yet.
>
> On Thu, Apr 19, 2018, 16:43 David Zuelke  > wrote:
>
> The main difference is that you have a release branch in which fixes
> to bugs or regressions found during 2.4.x RCs can be made, while work
> on 2.4.(x+1) can continue in the main 2.4 branch.
>
> Another benefit is that people who do automated builds (e.g. me) can
> grep for "RC" in the version number and have it fetch from
> https://dist.apache.org/repos/dist/dev/httpd/ instead.
>
> The changelogs are more readable as well, because it's obvious which
> intermediary RC releases belong together. If you look at
> https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> indication that e.g. 2.4.31 was never released.
>
>
> On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr
> > wrote:
> > What possible improvement occurs if there is no branch discipline
> > on 2.4.x development? We just echoed effectively your proposal,
> > using numbers rather than RC designations, and still .33 has this
> > host of issues. With no release since .29, the branch was in this
> > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > .31 didn't result in a better .32, and even the final .33 had
> its own
> > issues.
> >
> > This would have been precisely the same outcome between RC1
> > and RC4, if the project doesn't keep the branch stable for even the
> > week or months required to craft a successful release, and if that
> > occurs on 2.4.x branch, that is an interruption of effort towards
> > release n+1, frustrating contributors.
> >
> > Note we don't publish anything not approved by the PMC, so
> > there would be the same "vote" to release an RC.
> >
> > Net <-> net, this is the status quo which failed us so badly this
> > past winter (now with alphabetic characters!)
> >
> >
> > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  > wrote:
> >> The idea is encouraging and fostering a broader test audience.
> >>
> >>
> >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr
> 

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Daniel Ruggeri]

I don't think Stefan is proposing that we mindlessly ship based on an
arbitrary set of dates. That'd be too corporate :-)

I think in the past you mentioned that we have had features/fixes/Good
Stuff(tm) that was probably *ready*... just not yet released. I do
recall a few times where there have been fixes in 2.4.x branch that I
was frustrated as a user (burdened with the knowledge of a developer)
for having to wait to hit a release... so my main objective with the
automation is to simply make it simple to do a release so we aren't
entirely dependent on you and Bill to get those fixes/features/whatever
it may be into our users' hands.

Referring to the other message I just sent. I want to stress the fact
that now, with a few commands and *some* manual work (mostly when there
are CVEs to address), anyone can do a release. There's value in this -
especially given the fact that I truly did pore through and intensively
examine/internalize the documentation yet STILL managed to burn a
version number due to rookie mistakes. The third option along with
status quo or automation would be for the next unfortunate committer to
stumble through the process themselves and, possibly, make the same
mistakes I did.

Besides, heck... as you say, this is Open Source. We're volunteers and
this is the kind of stuff I actually do like to work on. CI/CD and the
like are a Good Thing :thumbsup:


Specifically to your question, Stefan... you beat me to it. Since the
last time I executed the release, I put in a quarterly reminder on my
calendar to check STATUS and help shuffle a release out the door if
there are no showstoppers and if we had added anything that looked cool.
I plan to stick by that schedule and also try to keep a pulse on the
project for times where we should ship a release sooner.

-- 
Daniel Ruggeri

On 4/19/2018 8:06 AM, Jim Jagielski wrote:
> One of the great things about working on open source is that
> one is NOT burdened by schedules. That releases are done
> "when ready" not when some artificial schedule or some
> calendar date demands. Changing this mindset on httpd would
> be an extremely major change, IMO, from what's been at its
> heart since 1995. Some may say that that is a good thing,
> that we need to "get inline with the times"... I would disagree,
> especially if we still want to encourage new contributions,
> new contributors and new (volunteer) committers.
>
> I submit that "doing a release" is not one of the problems that should
> be a priority to "fix".
>
>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing  
>> wrote:
>>
>> Daniel,
>>
>> would you find it feasible to make a 2.4 release every first Tuesday of the 
>> month? Other projects have excellent experiences with such release timings. 
>>
>> I‘d expect this would let us focus on the changes („one more week until 
>> release“), take off pressure („we can do it in the next release“), avoid 
>> meta discussions („is this a good time?“) and let us streamline the 
>> test/release work with changes in process/automation with a higher 
>> motivation.
>>
>> Again, this would be your burden and call until we have so much 
>> routine/automation that everyone can do it. So it needs to be your decision.
>>
>> Cheers, Stefan
>>
>>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
>>>
>>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
> The release cycle is hours, to the benefit of all interested. Be it a 
> blocking bug fixed or a nice feature implemented. These are mostly people 
> who do it for fun. Some even run large server clusters, so a „hobbyist“ 
> label does not apply.
 Hours, yes, but we've had a willing RM, who has automated even
 more of this than Jim or I had, and has a very hard time finding
 any target to point to. E.g. "ok, that looks like the right resolution
 to the last of the regressions... let's..." ... "...oh there are all these
 other shiny objects in STATUS... rock-n-roll!!!" 
 ...
>>> What's particularly interesting to me, as I follow the conversation in
>>> my usual lurker-mode, is that Bill hit the nail on the head with this
>>> observation. I was waiting for the dust to settle to run through the
>>> scripts again for another T and release vote... but am not totally
>>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>>> the merging discussion so instead started parsing for "Yep. We're good
>>> now.")
>>>
>>> My current read on the conversation is that we're happy (or maybe just
>>> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
>>> a fix. Does anyone disagree?
>>>
>>> -- 
>>> Daniel Ruggeri
>>>

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[William A Rowe Jr]

I don't disagree with RC's entirely, or the mechanism you suggest, but that
isn't what I read as proposed.

Our issue is that every httpd must be distinguished, we won't ship four
tarballs all claiming 2.4.34 (GA). Which one is the person complaining
about? Are we back to SHA signature of the source tarball (that isn't even
assuredly what they built the binary from?)

We can decorate the rc in the versioning, but that isn't part of 2.4.x API,
unless we swap out the "-dev" string tag for an "-rc#" value.

It is not reasonable to lock a branch for an indeterminate length of time.
Branching the RC into what becomes the final release, and making it painful
to backport first to 2.4.x and finally 2.4.n-rc branch might help
discourage disruptive backports, but there is no suggestion yet of what is
acceptable, either on such a frozen main branch or rc branch.

In fact our policy reflects that two competing release candidates is an
entire valid and even expected situation, and any process that further
blocks this should be firmly rebuffed.

As it reads so far the proposal is the way we do things, now conserving
subversion numbers as precious, if only to reenforce a stake in the ground
that version major and minor numbers are similarly precious, (which they
are not.)

With the addition of freezing changes on 2.4.x branch for a time we succeed
in impeading progress towards version .next, while not otherwise changing
the status quo.

What you suggest is yet another thing, based on forking the RC release
branch, and I haven't seen that accepted by the committee yet.

On Thu, Apr 19, 2018, 16:43 David Zuelke  wrote:

> The main difference is that you have a release branch in which fixes
> to bugs or regressions found during 2.4.x RCs can be made, while work
> on 2.4.(x+1) can continue in the main 2.4 branch.
>
> Another benefit is that people who do automated builds (e.g. me) can
> grep for "RC" in the version number and have it fetch from
> https://dist.apache.org/repos/dist/dev/httpd/ instead.
>
> The changelogs are more readable as well, because it's obvious which
> intermediary RC releases belong together. If you look at
> https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
> indication that e.g. 2.4.31 was never released.
>
>
> On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr 
> wrote:
> > What possible improvement occurs if there is no branch discipline
> > on 2.4.x development? We just echoed effectively your proposal,
> > using numbers rather than RC designations, and still .33 has this
> > host of issues. With no release since .29, the branch was in this
> > continuous state of flux between 2.4.30 and 2.4.33. Testing the
> > 2.4.30 release did not result in a better, eventual 2.4.31, testing
> > .31 didn't result in a better .32, and even the final .33 had its own
> > issues.
> >
> > This would have been precisely the same outcome between RC1
> > and RC4, if the project doesn't keep the branch stable for even the
> > week or months required to craft a successful release, and if that
> > occurs on 2.4.x branch, that is an interruption of effort towards
> > release n+1, frustrating contributors.
> >
> > Note we don't publish anything not approved by the PMC, so
> > there would be the same "vote" to release an RC.
> >
> > Net <-> net, this is the status quo which failed us so badly this
> > past winter (now with alphabetic characters!)
> >
> >
> > On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  wrote:
> >> The idea is encouraging and fostering a broader test audience.
> >>
> >>
> >> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr 
> wrote:
> >>
> >> Unless I misunderstand...
> >>
> >> 2.4.30-RC1 (rejected)
> >> 2.4.30-RC2 (our .31, rejected)
> >> 2.4.30-RC3 (our .32, rejected)
> >> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> >>
> >> With all the associated changes in between, no actual change in branch
> >> management, scope, feature creep, etc?
> >>
> >> This sounds like dressing up the status quo with different labels.
> >>
> >>
> >>
> >> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:
> >>>
> >>>
> >>>
> >>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  >
> >>> > wrote:
> >>> >
> >>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski 
> wrote:
> >>> >> With all this in mind, should we try to set things up so that the
> >>> >> next release cycle uses the concept of RCs?
> >>> >>
> >>> >> If so, and if people like, I can come up with a baseline
> >>> >> proposal on the process for us to debate and come to
> >>> >> some consensus on.
> >>> >
> >>> > Would you define an RC? What changes are allowable in that branch?
> >>>
> >>>
> >>> The idea is that right now we take an existing state in SVN
> >>> and tag it as, for example, 2.4.121. We then vote on that tag
> >>> and the artifacts released from that tag. No work is done on
> >>> the 2.4 branch 

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Daniel Ruggeri]

On 4/19/2018 7:55 AM, Eric Covener wrote:
>> Again, this would be your burden and call until we have so much 
>> routine/automation that everyone can do it. So it needs to be your decision.
> No offense intended here, but I did not really see as many html /
> script / process updates as I had expected. I was hoping the new eyes
> would get some of this stuff more explicit so it wasn't such a
> mystery.

Totally my fault. I just pushed the last bit of the scripts (I had set a
TODO to do it after we had reviewed in on private@, but failed to
complete the TODO). I still owe doc updates AND the promised docker
image to make the endeavor completely trivial but basically, I've
distilled the process down to this set of commands from the tools directory:

unset DISPLAY
TAG="2.4.33"
./tag.sh 2.4.x $TAG /tmp/foo
./release.sh --latestapxxx --tag $TAG '' httpd-2.4 $TAG
'drugg...@primary.net'
./push.sh . $TAG dev
#Wait for vote
./push.sh . $TAG dist
#Wait for mirrors
./announce.sh $TAG 'drugg...@apache.org' 'Daniel Ruggeri'

The only hangup so far is when we merge in security fixes right before
announce - if the patch in the private repo doesn't merge into CHANGES
cleanly, we end up with confusing CHANGES entries. This can be resolved
by a manual check or even an immediate fix after the script is run.
There are also a few XXX and TODO sections that could be addressed with
some more sophisticated automation.

-- 
Daniel Ruggeri

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[David Zuelke]

On Thu, Apr 19, 2018 at 11:07 PM, Mark Blackman  wrote:
>
>
>> On 19 Apr 2018, at 21:35, David Zuelke  wrote:
>>
>> I'm not saying no directives should ever be added in point releases or
>> anything, but the constant backporting of *features* to 2.4 has
>> contributed to the relatively high number of regressions, and to a
>> lack of progress on 2.6/3.0, because, well, if anything can be put
>> into 2.4.next, why bother?
>>
>> David
>
> What’s the rule for *features*?

That remains to be defined. Generally, I'd say anything that doesn't
correct existing functionality, or anything that changes defaults, or
anything that changes behavior with existing settings, is a
feature/break/change and not a fix, so would belong in 2.next.0.

More or less the Semver approach, essentially.

See e.g. https://wiki.php.net/rfc/releaseprocess

David

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[David Zuelke]

The main difference is that you have a release branch in which fixes
to bugs or regressions found during 2.4.x RCs can be made, while work
on 2.4.(x+1) can continue in the main 2.4 branch.

Another benefit is that people who do automated builds (e.g. me) can
grep for "RC" in the version number and have it fetch from
https://dist.apache.org/repos/dist/dev/httpd/ instead.

The changelogs are more readable as well, because it's obvious which
intermediary RC releases belong together. If you look at
https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
indication that e.g. 2.4.31 was never released.


On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr  wrote:
> What possible improvement occurs if there is no branch discipline
> on 2.4.x development? We just echoed effectively your proposal,
> using numbers rather than RC designations, and still .33 has this
> host of issues. With no release since .29, the branch was in this
> continuous state of flux between 2.4.30 and 2.4.33. Testing the
> 2.4.30 release did not result in a better, eventual 2.4.31, testing
> .31 didn't result in a better .32, and even the final .33 had its own
> issues.
>
> This would have been precisely the same outcome between RC1
> and RC4, if the project doesn't keep the branch stable for even the
> week or months required to craft a successful release, and if that
> occurs on 2.4.x branch, that is an interruption of effort towards
> release n+1, frustrating contributors.
>
> Note we don't publish anything not approved by the PMC, so
> there would be the same "vote" to release an RC.
>
> Net <-> net, this is the status quo which failed us so badly this
> past winter (now with alphabetic characters!)
>
>
> On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  wrote:
>> The idea is encouraging and fostering a broader test audience.
>>
>>
>> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr  wrote:
>>
>> Unless I misunderstand...
>>
>> 2.4.30-RC1 (rejected)
>> 2.4.30-RC2 (our .31, rejected)
>> 2.4.30-RC3 (our .32, rejected)
>> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>>
>> With all the associated changes in between, no actual change in branch
>> management, scope, feature creep, etc?
>>
>> This sounds like dressing up the status quo with different labels.
>>
>>
>>
>> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:
>>>
>>>
>>>
>>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>>> > wrote:
>>> >
>>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
>>> >> With all this in mind, should we try to set things up so that the
>>> >> next release cycle uses the concept of RCs?
>>> >>
>>> >> If so, and if people like, I can come up with a baseline
>>> >> proposal on the process for us to debate and come to
>>> >> some consensus on.
>>> >
>>> > Would you define an RC? What changes are allowable in that branch?
>>>
>>>
>>> The idea is that right now we take an existing state in SVN
>>> and tag it as, for example, 2.4.121. We then vote on that tag
>>> and the artifacts released from that tag. No work is done on
>>> the 2.4 branch while testing is done so that we ensure that
>>> the SVN rev on branch == the one for the tag
>>
>>
>> Not necessary to freeze; a tag can always be applied to an older rev.
>>
>>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>>> vote does not pass, we continue on the 2.4 branch, fix the
>>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>>
>>> If the vote does pass we tag the branch, which is still == RC#
>>> at this stage, as 2.4.121 (ap_release.h mods included). We
>>> still even at this stage test and vote on the release as we have
>>> for decades. If it passes, we release. If not, for some reason,
>>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>>> the above.
>>>
>>> This is the overall idea... more flesh to be added.
>>
>>

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Mark Blackman]

> On 19 Apr 2018, at 21:35, David Zuelke  wrote:
> 
> On Thu, Apr 19, 2018 at 8:25 PM, Jim Jagielski  wrote:
>> 
>> 
>>> On Apr 19, 2018, at 11:55 AM, David Zuelke  wrote:
>>> 
>>> 
>>> I hate to break this to you, and I do not want to discredit the
>>> amazing work all the contributors here are doing, but httpd 2.4 is of
>>> miserable, miserable quality when it comes to breaks and regressions.
>>> 
>> 
>> Gee Thanks! That is an amazing compliment to be sure. I have
>> NO idea how ANYONE could take that in any way as discrediting
>> the work being done.
>> 
>> Sarcasm aside, could we do better? Yes. Can we do better? Yes.
>> Should we do better? Yes. Will we do better? Yes.
>> 
>> BTW, you DID see how h2 actually came INTO httpd, didn't you??
> 
> Of course, but that's exactly my point. It was introduced not in
> 2.4.0, but in 2.4.17. Five "H2…" config directives are available in
> 2.4.18+ only, one in 2.4.19+, and three in 2.4.24+.
> 
> I'm not saying no directives should ever be added in point releases or
> anything, but the constant backporting of *features* to 2.4 has
> contributed to the relatively high number of regressions, and to a
> lack of progress on 2.6/3.0, because, well, if anything can be put
> into 2.4.next, why bother?
> 
> David

What’s the rule for *features*?

- Mark

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[William A Rowe Jr]

What possible improvement occurs if there is no branch discipline
on 2.4.x development? We just echoed effectively your proposal,
using numbers rather than RC designations, and still .33 has this
host of issues. With no release since .29, the branch was in this
continuous state of flux between 2.4.30 and 2.4.33. Testing the
2.4.30 release did not result in a better, eventual 2.4.31, testing
.31 didn't result in a better .32, and even the final .33 had its own
issues.

This would have been precisely the same outcome between RC1
and RC4, if the project doesn't keep the branch stable for even the
week or months required to craft a successful release, and if that
occurs on 2.4.x branch, that is an interruption of effort towards
release n+1, frustrating contributors.

Note we don't publish anything not approved by the PMC, so
there would be the same "vote" to release an RC.

Net <-> net, this is the status quo which failed us so badly this
past winter (now with alphabetic characters!)


On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  wrote:
> The idea is encouraging and fostering a broader test audience.
>
>
> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr  wrote:
>
> Unless I misunderstand...
>
> 2.4.30-RC1 (rejected)
> 2.4.30-RC2 (our .31, rejected)
> 2.4.30-RC3 (our .32, rejected)
> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>
> With all the associated changes in between, no actual change in branch
> management, scope, feature creep, etc?
>
> This sounds like dressing up the status quo with different labels.
>
>
>
> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:
>>
>>
>>
>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>> > wrote:
>> >
>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
>> >> With all this in mind, should we try to set things up so that the
>> >> next release cycle uses the concept of RCs?
>> >>
>> >> If so, and if people like, I can come up with a baseline
>> >> proposal on the process for us to debate and come to
>> >> some consensus on.
>> >
>> > Would you define an RC? What changes are allowable in that branch?
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag
>
>
> Not necessary to freeze; a tag can always be applied to an older rev.
>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
>

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[David Zuelke]

On Thu, Apr 19, 2018 at 8:25 PM, Jim Jagielski  wrote:
>
>
>> On Apr 19, 2018, at 11:55 AM, David Zuelke  wrote:
>>
>>
>> I hate to break this to you, and I do not want to discredit the
>> amazing work all the contributors here are doing, but httpd 2.4 is of
>> miserable, miserable quality when it comes to breaks and regressions.
>>
>
> Gee Thanks! That is an amazing compliment to be sure. I have
> NO idea how ANYONE could take that in any way as discrediting
> the work being done.
>
> Sarcasm aside, could we do better? Yes. Can we do better? Yes.
> Should we do better? Yes. Will we do better? Yes.
>
> BTW, you DID see how h2 actually came INTO httpd, didn't you??

Of course, but that's exactly my point. It was introduced not in
2.4.0, but in 2.4.17. Five "H2…" config directives are available in
2.4.18+ only, one in 2.4.19+, and three in 2.4.24+.

I'm not saying no directives should ever be added in point releases or
anything, but the constant backporting of *features* to 2.4 has
contributed to the relatively high number of regressions, and to a
lack of progress on 2.6/3.0, because, well, if anything can be put
into 2.4.next, why bother?

David

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[William A Rowe Jr]

All informative feedback is welcome on this /discussion/ thread.

Jim, again, stop. Bullying list watchers with negative feedback
into silence is a CoC violation.

David, thank you for your detailed feedback. We are reading,
whether the feedback is warmly received or not.



On Thu, Apr 19, 2018 at 1:25 PM, Jim Jagielski  wrote:
>
>
>> On Apr 19, 2018, at 11:55 AM, David Zuelke  wrote:
>>
>>
>> I hate to break this to you, and I do not want to discredit the
>> amazing work all the contributors here are doing, but httpd 2.4 is of
>> miserable, miserable quality when it comes to breaks and regressions.
>>
>
> Gee Thanks! That is an amazing compliment to be sure. I have
> NO idea how ANYONE could take that in any way as discrediting
> the work being done.
>
> Sarcasm aside, could we do better? Yes. Can we do better? Yes.
> Should we do better? Yes. Will we do better? Yes.
>
> BTW, you DID see how h2 actually came INTO httpd, didn't you??
>

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[David Zuelke]

Yup, that's exactly it. Have a release branch, iterate there, and in
the meantime, work in the version series branch can continue. That
brings one huge benefit over the current model already: no freezes
necessary, no potential additional breaks after a "burned" version.

On Thu, Apr 19, 2018 at 9:19 PM, Rainer Jung  wrote:
> Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>>
>>
>>
>>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>>> wrote:
>>>
>>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:

 With all this in mind, should we try to set things up so that the
 next release cycle uses the concept of RCs?

 If so, and if people like, I can come up with a baseline
 proposal on the process for us to debate and come to
 some consensus on.
>>>
>>>
>>> Would you define an RC? What changes are allowable in that branch?
>>
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag.
>>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
>
> IMHO we should aim at keeping the RC phase as stable as possible and focuse
> on the code from which we tagged RC1 and which we actually want to release.
> So after RC1 there should be only fixes for regressions, no other fixes or
> backports.
>
> Other projects for example branch at the start of the release process (using
> your version example 2.4.121 here):
>
> - branch 2.4.x as a 2.4.121 branch
> - tag 2.4.121-RC1 on that branch
> - allow for a week or two (?) of public testing
> - fix incoming regressions
>   - patches go via trunk to 2.4.x to 2.4.121 branch
> - cut new RCs if previous RC needed fixes
> - create final release tag from last RC plus some script driven version
> adjustments
> - do final release vote
>
> While we are doing RCs backport and other fixing work could proceed on the
> 2.4.x branch, because the RCs are created from the version branch.
>
> ... 2c ...
>
> Rainer

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[Rainer Jung]

Am 19.04.2018 um 17:37 schrieb Jim Jagielski:




On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  wrote:

On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:

With all this in mind, should we try to set things up so that the
next release cycle uses the concept of RCs?

If so, and if people like, I can come up with a baseline
proposal on the process for us to debate and come to
some consensus on.


Would you define an RC? What changes are allowable in that branch?



The idea is that right now we take an existing state in SVN
and tag it as, for example, 2.4.121. We then vote on that tag
and the artifacts released from that tag. No work is done on
the 2.4 branch while testing is done so that we ensure that
the SVN rev on branch == the one for the tag.

Instead, we tag at 2.4.121-RC1. We do the exact same. If the
vote does not pass, we continue on the 2.4 branch, fix the
issues, and then tag a 2.4.121-RC2. Rinse and repeat.

If the vote does pass we tag the branch, which is still == RC#
at this stage, as 2.4.121 (ap_release.h mods included). We
still even at this stage test and vote on the release as we have
for decades. If it passes, we release. If not, for some reason,
we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
the above.

This is the overall idea... more flesh to be added.


IMHO we should aim at keeping the RC phase as stable as possible and 
focuse on the code from which we tagged RC1 and which we actually want 
to release. So after RC1 there should be only fixes for regressions, no 
other fixes or backports.


Other projects for example branch at the start of the release process 
(using your version example 2.4.121 here):


- branch 2.4.x as a 2.4.121 branch
- tag 2.4.121-RC1 on that branch
- allow for a week or two (?) of public testing
- fix incoming regressions
  - patches go via trunk to 2.4.x to 2.4.121 branch
- cut new RCs if previous RC needed fixes
- create final release tag from last RC plus some script driven version 
adjustments

- do final release vote

While we are doing RCs backport and other fixing work could proceed on 
the 2.4.x branch, because the RCs are created from the version branch.


... 2c ...

Rainer

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Jim Jagielski]

> On Apr 19, 2018, at 11:55 AM, David Zuelke  wrote:
> 
> 
> I hate to break this to you, and I do not want to discredit the
> amazing work all the contributors here are doing, but httpd 2.4 is of
> miserable, miserable quality when it comes to breaks and regressions.
> 

Gee Thanks! That is an amazing compliment to be sure. I have
NO idea how ANYONE could take that in any way as discrediting
the work being done.

Sarcasm aside, could we do better? Yes. Can we do better? Yes.
Should we do better? Yes. Will we do better? Yes.

BTW, you DID see how h2 actually came INTO httpd, didn't you??

Re: 2.4.3x regression w/SSL vhost configs

[li...@rhsoft.net]

Am 19.04.2018 um 17:55 schrieb David Zuelke:
> I hate to break this to you, and I do not want to discredit the
> amazing work all the contributors here are doing, but httpd 2.4 is of
> miserable, miserable quality when it comes to breaks and regressions.
> 
> I maintain the PHP/Apache/Nginx infrastructure at Heroku, and I was
> able to use the following httpd releases only in the last ~2.5 years:
> 
> - 2.4.16
> - 2.4.18
> - 2.4.20
> - 2.4.29
>  -2.4.33

2.4.29 was a official release
2.4.33 was a official release

30, 31, 32 never was a release, the where at voting, regressions where
fund and fixed - so the gap 29-33 is as explected because a RC either
get released 1:1 or not at all

please review your numbers with the list-archive of rejected RC's

it's just bike-shedding if 30,31,32 should not have existed at all and
have been a 30RC1, 30RC2, 30RC3 -> 30GA but you where not supposed to
use 30, 31, 32 at all for anything than testing and report regressions

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[David Zuelke]

On Wed, Apr 18, 2018 at 8:01 AM, Stefan Eissing
 wrote:
>
>
>> Am 17.04.2018 um 19:18 schrieb William A Rowe Jr :
>>
>>> The architecture of v2.4 has been very stable, the need for breaking 
>>> changes has been largely non existent, and the focus since 2011 has been to 
>>> get changes backported to v2.4 instead.
>>>
>>> To distill this down to raw numbers, there have been 1546 discrete 
>>> backports (my simple grep of CHANGES) since 2011 - which has provided an 
>>> enormous amount of enhancement for the collective community’s scrutiny.
>>
>> And the corresponding number of regressions and behavior changes. None
>> of these have enjoyed an "RC" or "beta", whatever one calls it, to
>> validate before adoption - other than our claim of "best httpd yet".
>> It has been an entirely new kitchen sink on every subversion release.
>
> All my substantial functional additions had beta releases for months before 
> being voted into the 2.4.x branch. With binary beta packages available for 
> several platforms by several supporters.
>
> William, this painting our world a dark and miserable place is coming back 
> every few months. It is a disservice to the people who contribute changes 
> here.

I hate to break this to you, and I do not want to discredit the
amazing work all the contributors here are doing, but httpd 2.4 is of
miserable, miserable quality when it comes to breaks and regressions.

I maintain the PHP/Apache/Nginx infrastructure at Heroku, and I was
able to use the following httpd releases only in the last ~2.5 years:

- 2.4.16
- 2.4.18
- 2.4.20
- 2.4.29
 -2.4.33

Mostly because of regressions around mod_proxy(_fcgi), REDIRECT_URL, whatever.

This is not any person's fault. This is the fault of the process. The
process can be repaired: bugfixes only in 2.4.x, do RC cycles for
bugfix releases as well (that alone makes the changelog look a lot
less confusing, which is useful for the project's image, see also the
Nginx marketing/FUD discussion in the other thread), and start testing
new features in modules first.

It makes such little sense to land h2 support in 2.4.something, as
opposed to having it as an official "brand new, try it out" subproject
first, and then bundle it with 2.6.

Speaking of which, I'd also suggest dropping this odd/even number
meaning experimental/stable versioning scheme, since it only
aggravates the problem: never-ending experiments that go stale, maybe
even get half backported, and meanwhile are subconsciously perceived
as one more hurdle towards a next bigger release.

Really, I'd suggest taking a close look at the PHP release cycle, with
their schedules, their RFC policies, everything. As I said in that
other thread, the PHP project was in exactly the same spot a few years
ago and they have pulled themselves out of that mess with amazing
results.

I am also happy to make introductions to release managers and
maintainers there. Heck I am betting some of them would happily serve
as tutors for the httpd project ;) I'm certainly willing to help too.
But IMO you need a clean cut and shake up the entire process, not just
a little, because otherwise you won't get rid of some of the old
habits that have been plaguing the project.

David

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[Jim Jagielski]

The idea is encouraging and fostering a broader test audience.

> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr  wrote:
> 
> Unless I misunderstand...
> 
> 2.4.30-RC1 (rejected)
> 2.4.30-RC2 (our .31, rejected)
> 2.4.30-RC3 (our .32, rejected)
> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
> 
> With all the associated changes in between, no actual change in branch 
> management, scope, feature creep, etc?
> 
> This sounds like dressing up the status quo with different labels.
> 
> 
> 
> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  > wrote:
> 
> 
> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  > > wrote:
> > 
> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  > > wrote:
> >> With all this in mind, should we try to set things up so that the
> >> next release cycle uses the concept of RCs?
> >> 
> >> If so, and if people like, I can come up with a baseline
> >> proposal on the process for us to debate and come to
> >> some consensus on.
> > 
> > Would you define an RC? What changes are allowable in that branch?
> 
> 
> The idea is that right now we take an existing state in SVN
> and tag it as, for example, 2.4.121. We then vote on that tag
> and the artifacts released from that tag. No work is done on
> the 2.4 branch while testing is done so that we ensure that
> the SVN rev on branch == the one for the tag
> 
> Not necessary to freeze; a tag can always be applied to an older rev.
> 
> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> vote does not pass, we continue on the 2.4 branch, fix the
> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
> 
> If the vote does pass we tag the branch, which is still == RC#
> at this stage, as 2.4.121 (ap_release.h mods included). We
> still even at this stage test and vote on the release as we have
> for decades. If it passes, we release. If not, for some reason,
> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> the above.
> 
> This is the overall idea... more flesh to be added.

Re: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

[Jim Riggs]

Luca -

Here's the same thing standardizing on strn?cmp(). Not that you couldn't have 
done it yourself, but since I had it up, maybe this will save you 30 seconds. 
;-)


Index: server/core.c
===
--- server/core.c   (revision 1829439)
+++ server/core.c   (working copy)
@@ -4867,7 +4867,8 @@
static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
{
if (!s->error_fname || s->error_fname[0] == '|'
-|| strcmp(s->error_fname, "syslog") == 0) {
+|| strcmp(s->error_fname, "syslog") == 0
+|| strncmp(s->error_fname, "syslog:", 7) == 0) {
return APR_SUCCESS;
}
else {
@@ -5281,7 +5282,9 @@
apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
tmp = ap_server_root_relative(p, sconf->ap_document_root);
apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
-if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
+if (s->error_fname[0] != '|'
+&& strcmp(s->error_fname, "syslog") != 0
+&& strncmp(s->error_fname, "syslog:", 7) != 0)
tmp = ap_server_root_relative(p, s->error_fname);
else
tmp = s->error_fname;
@@ -5456,4 +5459,3 @@
core_cmds,/* command apr_table_t */
register_hooks/* register hooks */
};
-
Index: server/log.c
===
--- server/log.c(revision 1829439)
+++ server/log.c(working copy)
@@ -396,7 +396,8 @@
}

#ifdef HAVE_SYSLOG
-else if (!strncasecmp(s->error_fname, "syslog", 6)) {
+else if (strcmp(s->error_fname, "syslog") == 0
+ || strncmp(s->error_fname, "syslog:", 7) == 0) {
if ((fname = strchr(s->error_fname, ':'))) {
/* s->error_fname could be [level]:[tag] (see #60525) */
const char *tag;


> On 18 Apr 2018, at 13:32, Luca Toscano  wrote:
> 
> Thanks a lot Jim! I like your code change and the extra checks, but I'd 
> prefer to use strncmp if possible, also in log.c. 
> Feel free to amend the patch, or I'll do it tomorrow (I forgot the entry in 
> CHANGES too, your name should be on it :).
> 
> Luca
> 
> 2018-04-18 18:36 GMT+02:00 Jim Riggs :
> Fair enough. I'm fine standardizing either way. strn?cmp() is probably more 
> "correct". As it stands, though, the check in core is not actually checking 
> everything that log.c will handle.
> 
> 
>> On 18 Apr 2018, at 10:15, William A Rowe Jr  wrote:
>> 
>> On Wed, Apr 18, 2018 at 7:17 AM, Jim Riggs  wrote:
>>> I didn't think of this before, but there is one edge case this would miss: 
>>> if someone (for whatever reason) wants a relative ErrorLog *file* named 
>>> `syslog*', for example `ErrorLog "syslog-httpd.log"' or `ErrorLog 
>>> "syslog.log"'. It appears that this is already broken in server/log.c, 
>>> though. Also, log.c is using str(n)casecmp. The following would make things 
>>> consistent and handle this weird edge case. Thoughts?
>>> 
>>> Index: server/core.c
>>> ===
>>> --- server/core.c   (revision 1829431)
>>> +++ server/core.c   (working copy)
>>> @@ -4867,7 +4867,8 @@
>>> static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
>>> {
>>>if (!s->error_fname || s->error_fname[0] == '|'
>>> -|| strcmp(s->error_fname, "syslog") == 0) {
>>> +|| strcasecmp(s->error_fname, "syslog") == 0
>>> +|| strncasecmp(s->error_fname, "syslog:", 7) == 0) {
>>>return APR_SUCCESS;
>>>}
>>>else {
>>> @@ -5281,7 +5282,9 @@
>>>apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
>>>tmp = ap_server_root_relative(p, sconf->ap_document_root);
>>>apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
>>> -if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
>>> +if (s->error_fname[0] != '|'
>>> +&& strcasecmp(s->error_fname, "syslog") != 0
>>> +&& strncasecmp(s->error_fname, "syslog:", 7) != 0)
>>>tmp = ap_server_root_relative(p, s->error_fname);
>>>else
>>>tmp = s->error_fname;
>>> @@ -5456,4 +5459,3 @@
>>>core_cmds,/* command apr_table_t */
>>>register_hooks/* register hooks */
>>> };
>>> -
>>> Index: server/log.c
>>> ===
>>> --- server/log.c(revision 1829431)
>>> +++ server/log.c(working copy)
>>> @@ -396,7 +396,8 @@
>>>}
>>> 
>>> #ifdef HAVE_SYSLOG
>>> -else if (!strncasecmp(s->error_fname, "syslog", 6)) {
>>> +else if (strcasecmp(s->error_fname, "syslog") == 0
>>> + || strncasecmp(s->error_fname, "syslog:", 7) == 0) {
>>>if ((fname = strchr(s->error_fname, ':'))) {
>>>/* s->error_fname could be [level]:[tag] (see #60525) */
>>>const char *tag;

Re: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

[Jim Riggs]

Luca -

Here's the same thing standardizing on strn?cmp(). Not that you couldn't have 
done it yourself, but since I had it up, maybe this will save you 30 seconds. 
;-)


Index: server/core.c
===
--- server/core.c   (revision 1829439)
+++ server/core.c   (working copy)
@@ -4867,7 +4867,8 @@
 static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
 {
 if (!s->error_fname || s->error_fname[0] == '|'
-|| strcmp(s->error_fname, "syslog") == 0) {
+|| strcmp(s->error_fname, "syslog") == 0
+|| strncmp(s->error_fname, "syslog:", 7) == 0) {
 return APR_SUCCESS;
 }
 else {
@@ -5281,7 +5282,9 @@
 apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
 tmp = ap_server_root_relative(p, sconf->ap_document_root);
 apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
-if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
+if (s->error_fname[0] != '|'
+&& strcmp(s->error_fname, "syslog") != 0
+&& strncmp(s->error_fname, "syslog:", 7) != 0)
 tmp = ap_server_root_relative(p, s->error_fname);
 else
 tmp = s->error_fname;
@@ -5456,4 +5459,3 @@
 core_cmds,/* command apr_table_t */
 register_hooks/* register hooks */
 };
-
Index: server/log.c
===
--- server/log.c(revision 1829439)
+++ server/log.c(working copy)
@@ -396,7 +396,8 @@
 }

 #ifdef HAVE_SYSLOG
-else if (!strncasecmp(s->error_fname, "syslog", 6)) {
+else if (strcmp(s->error_fname, "syslog") == 0
+ || strncmp(s->error_fname, "syslog:", 7) == 0) {
 if ((fname = strchr(s->error_fname, ':'))) {
 /* s->error_fname could be [level]:[tag] (see #60525) */
 const char *tag;


> On 18 Apr 2018, at 13:32, Luca Toscano  wrote:
> 
> Thanks a lot Jim! I like your code change and the extra checks, but I'd 
> prefer to use strncmp if possible, also in log.c. 
> Feel free to amend the patch, or I'll do it tomorrow (I forgot the entry in 
> CHANGES too, your name should be on it :).
> 
> Luca
> 
> 2018-04-18 18:36 GMT+02:00 Jim Riggs :
> Fair enough. I'm fine standardizing either way. strn?cmp() is probably more 
> "correct". As it stands, though, the check in core is not actually checking 
> everything that log.c will handle.
> 
> 
> > On 18 Apr 2018, at 10:15, William A Rowe Jr  wrote:
> > 
> > On Wed, Apr 18, 2018 at 7:17 AM, Jim Riggs  wrote:
> >> I didn't think of this before, but there is one edge case this would miss: 
> >> if someone (for whatever reason) wants a relative ErrorLog *file* named 
> >> `syslog*', for example `ErrorLog "syslog-httpd.log"' or `ErrorLog 
> >> "syslog.log"'. It appears that this is already broken in server/log.c, 
> >> though. Also, log.c is using str(n)casecmp. The following would make 
> >> things consistent and handle this weird edge case. Thoughts?
> >> 
> >> Index: server/core.c
> >> ===
> >> --- server/core.c   (revision 1829431)
> >> +++ server/core.c   (working copy)
> >> @@ -4867,7 +4867,8 @@
> >> static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
> >> {
> >> if (!s->error_fname || s->error_fname[0] == '|'
> >> -|| strcmp(s->error_fname, "syslog") == 0) {
> >> +|| strcasecmp(s->error_fname, "syslog") == 0
> >> +|| strncasecmp(s->error_fname, "syslog:", 7) == 0) {
> >> return APR_SUCCESS;
> >> }
> >> else {
> >> @@ -5281,7 +5282,9 @@
> >> apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
> >> tmp = ap_server_root_relative(p, sconf->ap_document_root);
> >> apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
> >> -if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
> >> +if (s->error_fname[0] != '|'
> >> +&& strcasecmp(s->error_fname, "syslog") != 0
> >> +&& strncasecmp(s->error_fname, "syslog:", 7) != 0)
> >> tmp = ap_server_root_relative(p, s->error_fname);
> >> else
> >> tmp = s->error_fname;
> >> @@ -5456,4 +5459,3 @@
> >> core_cmds,/* command apr_table_t */
> >> register_hooks/* register hooks */
> >> };
> >> -
> >> Index: server/log.c
> >> ===
> >> --- server/log.c(revision 1829431)
> >> +++ server/log.c(working copy)
> >> @@ -396,7 +396,8 @@
> >> }
> >> 
> >> #ifdef HAVE_SYSLOG
> >> -else if (!strncasecmp(s->error_fname, "syslog", 6)) {
> >> +else if (strcasecmp(s->error_fname, "syslog") == 0
> >> + || strncasecmp(s->error_fname, "syslog:", 7) == 0) {
> >> if ((fname = strchr(s->error_fname, ':'))) {
> >> 

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[William A Rowe Jr]

Unless I misunderstand...

2.4.30-RC1 (rejected)
2.4.30-RC2 (our .31, rejected)
2.4.30-RC3 (our .32, rejected)
2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)

With all the associated changes in between, no actual change in branch
management, scope, feature creep, etc?

This sounds like dressing up the status quo with different labels.



On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:

>
>
> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
> wrote:
> >
> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
> >> With all this in mind, should we try to set things up so that the
> >> next release cycle uses the concept of RCs?
> >>
> >> If so, and if people like, I can come up with a baseline
> >> proposal on the process for us to debate and come to
> >> some consensus on.
> >
> > Would you define an RC? What changes are allowable in that branch?
>
>
> The idea is that right now we take an existing state in SVN
> and tag it as, for example, 2.4.121. We then vote on that tag
> and the artifacts released from that tag. No work is done on
> the 2.4 branch while testing is done so that we ensure that
> the SVN rev on branch == the one for the tag
>

Not necessary to freeze; a tag can always be applied to an older rev.

Instead, we tag at 2.4.121-RC1. We do the exact same. If the
> vote does not pass, we continue on the 2.4 branch, fix the
> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>
> If the vote does pass we tag the branch, which is still == RC#
> at this stage, as 2.4.121 (ap_release.h mods included). We
> still even at this stage test and vote on the release as we have
> for decades. If it passes, we release. If not, for some reason,
> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
> the above.
>
> This is the overall idea... more flesh to be added.

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[Jim Jagielski]

> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr  wrote:
> 
> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
>> With all this in mind, should we try to set things up so that the
>> next release cycle uses the concept of RCs?
>> 
>> If so, and if people like, I can come up with a baseline
>> proposal on the process for us to debate and come to
>> some consensus on.
> 
> Would you define an RC? What changes are allowable in that branch?


The idea is that right now we take an existing state in SVN
and tag it as, for example, 2.4.121. We then vote on that tag
and the artifacts released from that tag. No work is done on
the 2.4 branch while testing is done so that we ensure that
the SVN rev on branch == the one for the tag.

Instead, we tag at 2.4.121-RC1. We do the exact same. If the
vote does not pass, we continue on the 2.4 branch, fix the
issues, and then tag a 2.4.121-RC2. Rinse and repeat.

If the vote does pass we tag the branch, which is still == RC#
at this stage, as 2.4.121 (ap_release.h mods included). We
still even at this stage test and vote on the release as we have
for decades. If it passes, we release. If not, for some reason,
we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
the above.

This is the overall idea... more flesh to be added.

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[William A Rowe Jr]

On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
> With all this in mind, should we try to set things up so that the
> next release cycle uses the concept of RCs?
>
> If so, and if people like, I can come up with a baseline
> proposal on the process for us to debate and come to
> some consensus on.

Would you define an RC? What changes are allowable in that branch?

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[William A Rowe Jr]

On Thu, Apr 19, 2018 at 10:08 AM, Jim Jagielski  wrote:
>
>> On Apr 19, 2018, at 10:47 AM, William A Rowe Jr  wrote:
>>
>>  and BFDL/NIH-tier levels of "we don't do that, we do things this way... my 
>> way or the highway."
>
> That is not quite true nor fair.
>
> It does not take a BFDL/NIH-er, for example, to say "We don't
> release s/w under the GPLv3", nor if someone sez that, does
> that make them a BDFL. Nor does anyone have the ability
> to have anything like "my way or the highway" even stick.

We aren't discussing GPLv3 or any other ASF-wide policy here.
We are discussing how the HTTP Server project versions and
releases software for the public good. There are dozens of ways
we can accomplish that, all of which fit into ASF policy.

We operate by consensus. Which means, if any PMC member
is unwilling to accept change to our release or versioning, we are
stuck with status quo. Any time the argument against a change
becomes "that isn't how we have done it", the argument needs
to be judged by the success of that status quo.

This entire thread is predicated with my belief that the status quo
processes, not the code base or committers, has problems. All
the proposals made in previous threads on the subject were shouted
down, and the project release management, measured in bugs
and regressions, still suffers all the same issues as it has for a
number of years.

Could you be kind enough to point out where you have proposed
or accepted a change to the release process that we can use as
a starting point of a dialog? We are obviously not talking past
one another anymore that the process stands to be improved.

Since you have objected to each of my prior proposals (and all
those presented by others), I'd like to find out if we can converge
on one of your proposals?

Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[Jim Jagielski]

With all this in mind, should we try to set things up so that the
next release cycle uses the concept of RCs?

If so, and if people like, I can come up with a baseline
proposal on the process for us to debate and come to
some consensus on.

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Jim Jagielski]

> On Apr 19, 2018, at 10:47 AM, William A Rowe Jr  wrote:
> 
>  and BFDL/NIH-tier levels of "we don't do that, we do things this way... my 
> way or the highway."
> 

That is not quite true nor fair.

It does not take a BFDL/NIH-er, for example, to say "We don't
release s/w under the GPLv3", nor if someone sez that, does
that make them a BDFL. Nor does anyone have the ability
to have anything like "my way or the highway" even stick.
People can say it, sure, but I don't think anyone has,
unless, of course, in cases like the GPLv3 example above,
but then, obviously, it's not "my/their" way at all. It
is *our* way.

Please don't make this personal.

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[William A Rowe Jr]

On Thu, Apr 19, 2018, 09:32 Jim Jagielski  wrote:

>
>
> > On Apr 19, 2018, at 10:20 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
> >
> > Frankly, I think the current state of things does not work well. It
> seems folly to say we should change nothing, only have more stable releases.
>
> No one is saying we change *nothing*. There just seems to be disagreement
> that what we should change is from "release when it's ready" to "release
> when the calendar sez
>

No suggested changes have met with acceptance, other than "more tests" and
some undefined "more frequent" releases.

I have several years of threads to dev@ of your's and a couple other's
objections to every substantive change proposed to the underlying process
by myself and others. All offered to achieve more consistent results for
our users to count on. Generally with the rationals of "that wouldn't be
fun" or "that isn't the ASF spirit" and BFDL/NIH-tier levels of "we don't
do that, we do things this way... my way or the highway."

That's why I introduced the subject differently, no perscriptions. What
would you suggest we *change* that would be fun/make people happy/produce
"the best available version of httpd" on a regular basis? I'm 100% with
Stefan, changing nothing except expectations of "doing better" is pure
folly.

While it is great we have fun, that can't continue at the expense of
other's enjoyment, and the expense of perpetually broken "stable" releases.

>

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Jim Jagielski]

> On Apr 19, 2018, at 10:20 AM, Stefan Eissing  
> wrote:
> 
> Frankly, I think the current state of things does not work well. It seems 
> folly to say we should change nothing, only have more stable releases.

No one is saying we change *nothing*. There just seems to be disagreement that 
what we should change is from "release when it's ready" to "release when the 
calendar sez"

Re: Expanding httpd adoption internationally - POC

[Eric Covener]

On Thu, Apr 19, 2018 at 10:24 AM, Eric Covener  wrote:
> On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener  wrote:
>>> If using gettext, there are some tools to check for that.
>>
>> Would be nice to put some feelers out to $bigcos to make sure we
>> choose a format they'd accomoddate [if they were otherwise willing to
>> donate a one-time translation]
>>
>
> The IBM formats do not look very promising w/o import/export.
> (and I didn't even consider how I'd get someone to pay)

Strike that, I realize now they assign proprietary identifiers to
normal formats.  So if we use gettext IBM would be a candidate.




-- 
Eric Covener
cove...@gmail.com

Re: Expanding httpd adoption internationally - POC

[Eric Covener]

On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener  wrote:
>> If using gettext, there are some tools to check for that.
>
> Would be nice to put some feelers out to $bigcos to make sure we
> choose a format they'd accomoddate [if they were otherwise willing to
> donate a one-time translation]
>

The IBM formats do not look very promising w/o import/export.
(and I didn't even consider how I'd get someone to pay)

Re: "Most Popular Web Server?"

[Rich Bowen]

On 04/19/2018 05:43 AM, Nick Kew wrote:

If you want to get writing at a serious level, that’ll be great!  I might even 
contribute
if you can get some momentum going, but I’d never attempt to take a lead, not
least because potential conflict-of-interest with my publisher’s copyright.


+1,000,000

Related, I just attended a presentation at work about how documentation 
(in OpenStack in particular) is part of the engineering process from the 
beginning, and how they work things into the product management process. 
It was very inspiring, and it's something that we actually do pretty 
well in httpd, although we're less intentional about it, possibly?


I'm still very proud of our docs, and we've managed to retain a pretty 
good team of writers over the years.

Re: cygwin-oriented scripts that grab deps, cmake, etc for win build?

[Eric Covener]

On Thu, Apr 19, 2018 at 9:38 AM, William A Rowe Jr  wrote:
> On Thu, Apr 19, 2018 at 7:52 AM, Eric Covener  wrote:
>> Hi All, sorry for the lazyness, but does anyone have even a partial
>> set of scripts to drive the windows cmake build including obtaining
>> common prereqs?
>>
>> I believe I have seen 1 or two batch oriented ones that I'd just as
>> well avoid 'cept for hints about how to do it in bash/cygwin.
>
> Something like https://github.com/appsuite/oss-httpd-build ?. The
> downside is that there is no corresponding mak/Makefile.gather-win,
> but my focus is on adding mak/Makefile.test-win first.
>
> The Ubuntu on Windows makes the unix/bash work out fine, (with
> a splash of apr-1.6.3\build\lineends.pl from src/ added for editability
> and behavior) and the two missing gather steps are falling back
> from a project's candidate tarball to their last release tarball, and
> validating gpg sigs. These later two things are hard enough to
> make me swap out the approach of Makefile/bash for python
> (not sure I have the patience to attack PowerShell this moment.)

Looks promising, thanks!  I don't think the limitations would affect
my use case. I will give it a spin.


-- 
Eric Covener
cove...@gmail.com

Re: AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Stefan Eissing]

Frankly, I think the current state of things does not work well. It seems folly 
to say we should change nothing, only have more stable releases.

Our current approach gave us around 6 months of „ship when it‘s ready“ and the 
quality is not what we want - as expressed by Jim, Bill and others.

Why a regular 2.4 release is in conflict with „ship when it‘s ready“ I do not 
understand. Surely, we only backport when it‘s ready? Where is this connected?

> Am 19.04.2018 um 15:41 schrieb Plüm, Rüdiger, Vodafone Group 
> :
> 
> I am also more in the "ship when it is ready", then "ship when it is time" 
> boat.
> We probably could have some automated "nightlyies" which are not releases in 
> the ASF sense (as release requires voting),
> but only some sort of convenience transformation of an svn export / co that 
> creates a tar ball.
> But this only creates value if a broader audience tests them.
> But I guess most people that benefit from this easier processing of 
> "nightlyies" would only test them when they see that
> something interesting is contained for them.
> Which brings us back to "ship when its ready". OTOH " nightlyies" would add 
> testers that have different / their own
> criteria's on "when it is ready"
> 
> Regards
> 
> Rüdiger
> 
>> -Ursprüngliche Nachricht-
>> Von: Jim Jagielski 
>> Gesendet: Donnerstag, 19. April 2018 15:06
>> An: dev@httpd.apache.org
>> Betreff: Re: So... when should we do 2.4.34? [WAS: Re: Revisit
>> Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
>> 
>> One of the great things about working on open source is that
>> one is NOT burdened by schedules. That releases are done
>> "when ready" not when some artificial schedule or some
>> calendar date demands. Changing this mindset on httpd would
>> be an extremely major change, IMO, from what's been at its
>> heart since 1995. Some may say that that is a good thing,
>> that we need to "get inline with the times"... I would disagree,
>> especially if we still want to encourage new contributions,
>> new contributors and new (volunteer) committers.
>> 
>> I submit that "doing a release" is not one of the problems that should
>> be a priority to "fix".
>> 
>>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing
>>  wrote:
>>> 
>>> Daniel,
>>> 
>>> would you find it feasible to make a 2.4 release every first Tuesday
>> of the month? Other projects have excellent experiences with such
>> release timings.
>>> 
>>> I‘d expect this would let us focus on the changes („one more week
>> until release“), take off pressure („we can do it in the next release“),
>> avoid meta discussions („is this a good time?“) and let us streamline
>> the test/release work with changes in process/automation with a higher
>> motivation.
>>> 
>>> Again, this would be your burden and call until we have so much
>> routine/automation that everyone can do it. So it needs to be your
>> decision.
>>> 
>>> Cheers, Stefan
>>> 
 Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
 
 On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>> The release cycle is hours, to the benefit of all interested. Be it
>> a blocking bug fixed or a nice feature implemented. These are mostly
>> people who do it for fun. Some even run large server clusters, so a
>> „hobbyist“ label does not apply.
> Hours, yes, but we've had a willing RM, who has automated even
> more of this than Jim or I had, and has a very hard time finding
> any target to point to. E.g. "ok, that looks like the right
>> resolution
> to the last of the regressions... let's..." ... "...oh there are all
>> these
> other shiny objects in STATUS... rock-n-roll!!!"
> ...
 
 What's particularly interesting to me, as I follow the conversation
>> in
 my usual lurker-mode, is that Bill hit the nail on the head with this
 observation. I was waiting for the dust to settle to run through the
 scripts again for another T and release vote... but am not totally
 sure if we're ready. (mea culpa: my brain melted as I tried to follow
 the merging discussion so instead started parsing for "Yep. We're
>> good
 now.")
 
 My current read on the conversation is that we're happy (or maybe
>> just
 content) with the SSL merging fixes and we should prep to ship 2.4.34
>> as
 a fix. Does anyone disagree?
 
 --
 Daniel Ruggeri
 
>>> 
> 

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Luca Toscano]

2018-04-19 15:40 GMT+02:00 Eric Covener :

> On Thu, Apr 19, 2018 at 9:31 AM, Jim Jagielski  wrote:
> > I agree a case could be made for considering adding an RC stage
> > to our release process... it would require some additional tooling
> > and some sort of additions to ap_release.h but nothing insurmountable.
> >
> > That might be a nice small-and-easily-reversable step to address
> > some of the issues that we've been having lately.
>
> Including burning version numbers!
>

+1

AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Plüm , Rüdiger , Vodafone Group]

I am also more in the "ship when it is ready", then "ship when it is time" boat.
We probably could have some automated "nightlyies" which are not releases in 
the ASF sense (as release requires voting),
but only some sort of convenience transformation of an svn export / co that 
creates a tar ball.
But this only creates value if a broader audience tests them.
But I guess most people that benefit from this easier processing of 
"nightlyies" would only test them when they see that
something interesting is contained for them.
Which brings us back to "ship when its ready". OTOH " nightlyies" would add 
testers that have different / their own
criteria's on "when it is ready"

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Jim Jagielski 
> Gesendet: Donnerstag, 19. April 2018 15:06
> An: dev@httpd.apache.org
> Betreff: Re: So... when should we do 2.4.34? [WAS: Re: Revisit
> Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
> 
> One of the great things about working on open source is that
> one is NOT burdened by schedules. That releases are done
> "when ready" not when some artificial schedule or some
> calendar date demands. Changing this mindset on httpd would
> be an extremely major change, IMO, from what's been at its
> heart since 1995. Some may say that that is a good thing,
> that we need to "get inline with the times"... I would disagree,
> especially if we still want to encourage new contributions,
> new contributors and new (volunteer) committers.
> 
> I submit that "doing a release" is not one of the problems that should
> be a priority to "fix".
> 
> > On Apr 19, 2018, at 1:24 AM, Stefan Eissing
>  wrote:
> >
> > Daniel,
> >
> > would you find it feasible to make a 2.4 release every first Tuesday
> of the month? Other projects have excellent experiences with such
> release timings.
> >
> > I‘d expect this would let us focus on the changes („one more week
> until release“), take off pressure („we can do it in the next release“),
> avoid meta discussions („is this a good time?“) and let us streamline
> the test/release work with changes in process/automation with a higher
> motivation.
> >
> > Again, this would be your burden and call until we have so much
> routine/automation that everyone can do it. So it needs to be your
> decision.
> >
> > Cheers, Stefan
> >
> >> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
> >>
> >> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>  The release cycle is hours, to the benefit of all interested. Be it
> a blocking bug fixed or a nice feature implemented. These are mostly
> people who do it for fun. Some even run large server clusters, so a
> „hobbyist“ label does not apply.
> >>> Hours, yes, but we've had a willing RM, who has automated even
> >>> more of this than Jim or I had, and has a very hard time finding
> >>> any target to point to. E.g. "ok, that looks like the right
> resolution
> >>> to the last of the regressions... let's..." ... "...oh there are all
> these
> >>> other shiny objects in STATUS... rock-n-roll!!!"
> >>> ...
> >>
> >> What's particularly interesting to me, as I follow the conversation
> in
> >> my usual lurker-mode, is that Bill hit the nail on the head with this
> >> observation. I was waiting for the dust to settle to run through the
> >> scripts again for another T and release vote... but am not totally
> >> sure if we're ready. (mea culpa: my brain melted as I tried to follow
> >> the merging discussion so instead started parsing for "Yep. We're
> good
> >> now.")
> >>
> >> My current read on the conversation is that we're happy (or maybe
> just
> >> content) with the SSL merging fixes and we should prep to ship 2.4.34
> as
> >> a fix. Does anyone disagree?
> >>
> >> --
> >> Daniel Ruggeri
> >>
> >

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Eric Covener]

On Thu, Apr 19, 2018 at 9:31 AM, Jim Jagielski  wrote:
> I agree a case could be made for considering adding an RC stage
> to our release process... it would require some additional tooling
> and some sort of additions to ap_release.h but nothing insurmountable.
>
> That might be a nice small-and-easily-reversable step to address
> some of the issues that we've been having lately.

Including burning version numbers!

Re: cygwin-oriented scripts that grab deps, cmake, etc for win build?

[William A Rowe Jr]

On Thu, Apr 19, 2018 at 7:52 AM, Eric Covener  wrote:
> Hi All, sorry for the lazyness, but does anyone have even a partial
> set of scripts to drive the windows cmake build including obtaining
> common prereqs?
>
> I believe I have seen 1 or two batch oriented ones that I'd just as
> well avoid 'cept for hints about how to do it in bash/cygwin.

Something like https://github.com/appsuite/oss-httpd-build ?. The
downside is that there is no corresponding mak/Makefile.gather-win,
but my focus is on adding mak/Makefile.test-win first.

The Ubuntu on Windows makes the unix/bash work out fine, (with
a splash of apr-1.6.3\build\lineends.pl from src/ added for editability
and behavior) and the two missing gather steps are falling back
from a project's candidate tarball to their last release tarball, and
validating gpg sigs. These later two things are hard enough to
make me swap out the approach of Makefile/bash for python
(not sure I have the patience to attack PowerShell this moment.)

Re: Expanding httpd adoption internationally - POC

[Eric Covener]

> If using gettext, there are some tools to check for that.

Would be nice to put some feelers out to $bigcos to make sure we
choose a format they'd accomoddate [if they were otherwise willing to
donate a one-time translation]

-- 
Eric Covener
cove...@gmail.com

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Jim Jagielski]

I agree a case could be made for considering adding an RC stage
to our release process... it would require some additional tooling
and some sort of additions to ap_release.h but nothing insurmountable.

That might be a nice small-and-easily-reversable step to address
some of the issues that we've been having lately.

> On Apr 19, 2018, at 9:25 AM, Steffen  wrote:
> 
> ++1
> 
> The current versioning and times are fine for me. Only the vote time is too 
> short. At Apachelounge I have once in a while  RC’s from branches before 
> voting, so the community had more time to test.  Issues are then earlier 
> discovered.  
> 
> Distributors are free to have a RC any time when they think, looking at 
> changes in branches, it helps. 
> 
>> Op 19 apr. 2018 om 15:06 heeft Jim Jagielski  het volgende 
>> geschreven:
>> 
>> One of the great things about working on open source is that
>> one is NOT burdened by schedules. That releases are done
>> "when ready" not when some artificial schedule or some
>> calendar date demands. Changing this mindset on httpd would
>> be an extremely major change, IMO, from what's been at its
>> heart since 1995. Some may say that that is a good thing,
>> that we need to "get inline with the times"... I would disagree,
>> especially if we still want to encourage new contributions,
>> new contributors and new (volunteer) committers.
>> 
>> I submit that "doing a release" is not one of the problems that should
>> be a priority to "fix".
>> 
>>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing  
>>> wrote:
>>> 
>>> Daniel,
>>> 
>>> would you find it feasible to make a 2.4 release every first Tuesday of the 
>>> month? Other projects have excellent experiences with such release timings. 
>>> 
>>> I‘d expect this would let us focus on the changes („one more week until 
>>> release“), take off pressure („we can do it in the next release“), avoid 
>>> meta discussions („is this a good time?“) and let us streamline the 
>>> test/release work with changes in process/automation with a higher 
>>> motivation.
>>> 
>>> Again, this would be your burden and call until we have so much 
>>> routine/automation that everyone can do it. So it needs to be your decision.
>>> 
>>> Cheers, Stefan
>>> 
 Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
 
 On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>> The release cycle is hours, to the benefit of all interested. Be it a 
>> blocking bug fixed or a nice feature implemented. These are mostly 
>> people who do it for fun. Some even run large server clusters, so a 
>> „hobbyist“ label does not apply.
> Hours, yes, but we've had a willing RM, who has automated even
> more of this than Jim or I had, and has a very hard time finding
> any target to point to. E.g. "ok, that looks like the right resolution
> to the last of the regressions... let's..." ... "...oh there are all these
> other shiny objects in STATUS... rock-n-roll!!!" 
> ...
 
 What's particularly interesting to me, as I follow the conversation in
 my usual lurker-mode, is that Bill hit the nail on the head with this
 observation. I was waiting for the dust to settle to run through the
 scripts again for another T and release vote... but am not totally
 sure if we're ready. (mea culpa: my brain melted as I tried to follow
 the merging discussion so instead started parsing for "Yep. We're good
 now.")
 
 My current read on the conversation is that we're happy (or maybe just
 content) with the SSL merging fixes and we should prep to ship 2.4.34 as
 a fix. Does anyone disagree?
 
 -- 
 Daniel Ruggeri
 
>>> 
>> 
> 

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Steffen]

++1

The current versioning and times are fine for me. Only the vote time is too 
short. At Apachelounge I have once in a while  RC’s from branches before 
voting, so the community had more time to test.  Issues are then earlier 
discovered.  

Distributors are free to have a RC any time when they think, looking at changes 
in branches, it helps. 

> Op 19 apr. 2018 om 15:06 heeft Jim Jagielski  het volgende 
> geschreven:
> 
> One of the great things about working on open source is that
> one is NOT burdened by schedules. That releases are done
> "when ready" not when some artificial schedule or some
> calendar date demands. Changing this mindset on httpd would
> be an extremely major change, IMO, from what's been at its
> heart since 1995. Some may say that that is a good thing,
> that we need to "get inline with the times"... I would disagree,
> especially if we still want to encourage new contributions,
> new contributors and new (volunteer) committers.
> 
> I submit that "doing a release" is not one of the problems that should
> be a priority to "fix".
> 
>> On Apr 19, 2018, at 1:24 AM, Stefan Eissing  
>> wrote:
>> 
>> Daniel,
>> 
>> would you find it feasible to make a 2.4 release every first Tuesday of the 
>> month? Other projects have excellent experiences with such release timings. 
>> 
>> I‘d expect this would let us focus on the changes („one more week until 
>> release“), take off pressure („we can do it in the next release“), avoid 
>> meta discussions („is this a good time?“) and let us streamline the 
>> test/release work with changes in process/automation with a higher 
>> motivation.
>> 
>> Again, this would be your burden and call until we have so much 
>> routine/automation that everyone can do it. So it needs to be your decision.
>> 
>> Cheers, Stefan
>> 
>>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
>>> 
>>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
> The release cycle is hours, to the benefit of all interested. Be it a 
> blocking bug fixed or a nice feature implemented. These are mostly people 
> who do it for fun. Some even run large server clusters, so a „hobbyist“ 
> label does not apply.
 Hours, yes, but we've had a willing RM, who has automated even
 more of this than Jim or I had, and has a very hard time finding
 any target to point to. E.g. "ok, that looks like the right resolution
 to the last of the regressions... let's..." ... "...oh there are all these
 other shiny objects in STATUS... rock-n-roll!!!" 
 ...
>>> 
>>> What's particularly interesting to me, as I follow the conversation in
>>> my usual lurker-mode, is that Bill hit the nail on the head with this
>>> observation. I was waiting for the dust to settle to run through the
>>> scripts again for another T and release vote... but am not totally
>>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>>> the merging discussion so instead started parsing for "Yep. We're good
>>> now.")
>>> 
>>> My current read on the conversation is that we're happy (or maybe just
>>> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
>>> a fix. Does anyone disagree?
>>> 
>>> -- 
>>> Daniel Ruggeri
>>> 
>> 
> 

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Jim Jagielski]

One of the great things about working on open source is that
one is NOT burdened by schedules. That releases are done
"when ready" not when some artificial schedule or some
calendar date demands. Changing this mindset on httpd would
be an extremely major change, IMO, from what's been at its
heart since 1995. Some may say that that is a good thing,
that we need to "get inline with the times"... I would disagree,
especially if we still want to encourage new contributions,
new contributors and new (volunteer) committers.

I submit that "doing a release" is not one of the problems that should
be a priority to "fix".

> On Apr 19, 2018, at 1:24 AM, Stefan Eissing  
> wrote:
> 
> Daniel,
> 
> would you find it feasible to make a 2.4 release every first Tuesday of the 
> month? Other projects have excellent experiences with such release timings. 
> 
> I‘d expect this would let us focus on the changes („one more week until 
> release“), take off pressure („we can do it in the next release“), avoid meta 
> discussions („is this a good time?“) and let us streamline the test/release 
> work with changes in process/automation with a higher motivation.
> 
> Again, this would be your burden and call until we have so much 
> routine/automation that everyone can do it. So it needs to be your decision.
> 
> Cheers, Stefan
> 
>> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
>> 
>> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
 The release cycle is hours, to the benefit of all interested. Be it a 
 blocking bug fixed or a nice feature implemented. These are mostly people 
 who do it for fun. Some even run large server clusters, so a „hobbyist“ 
 label does not apply.
>>> Hours, yes, but we've had a willing RM, who has automated even
>>> more of this than Jim or I had, and has a very hard time finding
>>> any target to point to. E.g. "ok, that looks like the right resolution
>>> to the last of the regressions... let's..." ... "...oh there are all these
>>> other shiny objects in STATUS... rock-n-roll!!!" 
>>> ...
>> 
>> What's particularly interesting to me, as I follow the conversation in
>> my usual lurker-mode, is that Bill hit the nail on the head with this
>> observation. I was waiting for the dust to settle to run through the
>> scripts again for another T and release vote... but am not totally
>> sure if we're ready. (mea culpa: my brain melted as I tried to follow
>> the merging discussion so instead started parsing for "Yep. We're good
>> now.")
>> 
>> My current read on the conversation is that we're happy (or maybe just
>> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
>> a fix. Does anyone disagree?
>> 
>> -- 
>> Daniel Ruggeri
>> 
> 

Re: "Most Popular Web Server?"

[Jim Jagielski]

> On Apr 19, 2018, at 6:29 AM, Dirk-Willem van Gulik  
> wrote:
> 
> 
> Large crude oil tankers and formula 1 racing cars are both things that can go 
> from A to B. Yet they have different qualities. 
> 
> Perhaps we need to emphasise this a bit more - that there is room for 
> different things in this market. 
> 
> I’ve found the same in production - nginx can be wonderfully fast in certain 
> settings - but can also be a relatively fragile and finicky beast best ran in 
> serious loadbalancing/failover.
> 

Agreed. Again, I think that working w/ Sally can help here, assuming
we get enough people interested in it that we can make a go of it.

Re: [Bug 62308] New: Apache crashes after graceful restart with AH02599: slotmem (failed size check)

[Jim Jagielski]

Bill, you continue to ignore the fact that I use the term "*we*"

"We" is *inclusive*.

Again, in your continued efforts to win points and cast
aspersions, you completely miss the point.

> On Apr 18, 2018, at 10:26 PM, William A Rowe Jr  wrote:
> 
> Does the root of this issue go back to this backport?
> 
> Author: minfrin
> Date: Tue Feb 13 22:11:47 2018
> New Revision: 1824180
> 
> URL: http://svn.apache.org/viewvc?rev=1824180=rev
> Log:
> mod_proxy_balancer,mod_slotmem_shm: Rework SHM reuse/deletion to not
> depend on the number of restarts (non-Unix systems) and preserve shared
> names as much as possible on configuration changes for SHMs and persisted
> files.  PR 62044.
> trunk patch: http://svn.apache.org/r1822509
> http://svn.apache.org/r1822511
> http://svn.apache.org/r1823412
> http://svn.apache.org/r1823415
> http://svn.apache.org/r1823416
> http://svn.apache.org/r1823564
> http://svn.apache.org/r1823572
> http://svn.apache.org/r1823575
> 2.4.x patch: trunk works (modulo CHANGES)
> (or
> http://home.apache.org/~ylavic/patches/httpd-2.4.x-PR62044-slotmems_reuse.patch)
> +1: ylavic, jim, minfrin
> 
> 
> If that's true, certain protestations over the horrors of refactoring are
> obvious crocodile tears, perhaps owing to a lack of actual evalution
> of the code one votes up +1 with insufficient (no?) attention to detail?
> 
> Each reviewer voting up a backport shares the full ownership of any
> such change on behalf of HTTP Server project, and the shares in the
> collective mea culpa. If that reviewer were to try to lay all blame on the
> original author of such a patch... wow... shameful.
> 
> 
> On Wed, Apr 18, 2018 at 9:01 AM, Yann Ylavic  wrote:
>> This isn't fair Jim, the previous code didn't work as expected either, IMHO.
>> 
>> Regarding PR 62277 for instance, it worked because it attach()ed SHMs
>> of unrelated balancers instead of creating new ones (this was the
>> paper over SysV vs Posix, not the actual code which I think shows the
>> real/potential issue on some systems).
>> 
>> For this PR 62308, let's see if this is a crash or the annoying AH02599 
>> "only".
>> In both cases "mea culpa maxima" (flogging myself and so on) but yes
>> changes can be buggy and I don't see why you seem to imply that all
>> this was gratuitous and for the sake of changing/breaking code. It was
>> intended to be bug fixes only, any bug revealed by the previous being
>> fixed itself fixed, when should we give up? I don't...
>> 
>> Please let's be constructive and not impugn motives on why a code is
>> changed, it's sometimes simply needed, and in any case open to
>> review/feedback/veto/tests at any time, including when it's proposed
>> for backport.
>> 
>> 
>> On Wed, Apr 18, 2018 at 1:56 PM, Jim Jagielski  wrote:
>>> Most likely it is due to some assumptions in slotmem based on the underlying
>>> shm implementation, ie: SysV or Posix.
>>> 
>>> I would be remiss is pointing out that here is yet another case where
>>> instead of a simple fix for a bug, we instead refactored a sh*t-ton of code
>>> and in the process, broke stuff.
>>> 
>>> Can we PLEASE avoid using bug reports as opportunities to
>>> show everyone how smart we are and rewrite whole swaths of
>>> code... please!
>>> 
>>> 
>>> On Apr 17, 2018, at 12:37 PM, Exonetric  wrote:
>>> 
>>> FWIW, I am seeing this too, but examining the code I could not see how. It
>>> looks like it just does a shm destroy and then moves on to recreating the
>>> SHM segment.
>>> 
>>> On 17 Apr 2018, at 14:03, Jim Jagielski  wrote:
>>> 
>>> This should not be a fatal error... I don't think it was before.
>>> 
>>> Begin forwarded message:
>>> 
>>> From: bugzi...@apache.org
>>> Subject: [Bug 62308] New: Apache crashes after graceful restart with
>>> AH02599: slotmem (failed size check)
>>> Date: April 17, 2018 at 6:21:09 AM EDT
>>> To: b...@httpd.apache.org
>>> Reply-To: "Apache HTTPD Bugs Notification List" 
>>> 
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=62308
>>> 
>>>   Bug ID: 62308
>>>  Summary: Apache crashes after graceful restart with AH02599:
>>>   slotmem (failed size check)
>>>  Product: Apache httpd-2
>>>  Version: 2.4.33
>>> Hardware: PC
>>>   Status: NEW
>>> Severity: regression
>>> Priority: P2
>>>Component: mod_proxy_balancer
>>> Assignee: b...@httpd.apache.org
>>> Reporter: d...@d-velop.de
>>> Target Milestone: ---
>>> 
>>> Created attachment 35878
>>> --> https://bz.apache.org/bugzilla/attachment.cgi?id=35878=edit
>>> logfile with configuration change example
>>> 
>>> After updating from 2.4.27 to 2.4.33, we get a crash when doing a graceful
>>> restart after modifying the mod_proxy/mod_proxy_balancer configuration in
>>> the
>>> 

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Eric Covener]

> Again, this would be your burden and call until we have so much 
> routine/automation that everyone can do it. So it needs to be your decision.

No offense intended here, but I did not really see as many html /
script / process updates as I had expected. I was hoping the new eyes
would get some of this stuff more explicit so it wasn't such a
mystery.

Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Eric Covener]

On Wed, Apr 18, 2018 at 6:43 PM, Daniel Ruggeri  wrote:
> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>> The release cycle is hours, to the benefit of all interested. Be it a 
>>> blocking bug fixed or a nice feature implemented. These are mostly people 
>>> who do it for fun. Some even run large server clusters, so a „hobbyist“ 
>>> label does not apply.
>> Hours, yes, but we've had a willing RM, who has automated even
>> more of this than Jim or I had, and has a very hard time finding
>> any target to point to. E.g. "ok, that looks like the right resolution
>> to the last of the regressions... let's..." ... "...oh there are all these
>> other shiny objects in STATUS... rock-n-roll!!!"
>> ...
>
> What's particularly interesting to me, as I follow the conversation in
> my usual lurker-mode, is that Bill hit the nail on the head with this
> observation. I was waiting for the dust to settle to run through the
> scripts again for another T and release vote... but am not totally
> sure if we're ready. (mea culpa: my brain melted as I tried to follow
> the merging discussion so instead started parsing for "Yep. We're good
> now.")
>
> My current read on the conversation is that we're happy (or maybe just
> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
> a fix. Does anyone disagree?

I am not sure we have that fix yet in 2.4.x yet.

I think we should call the proxy thing (62308) a showstopper and not
roll a release without it.

cygwin-oriented scripts that grab deps, cmake, etc for win build?

[Eric Covener]

Hi All, sorry for the lazyness, but does anyone have even a partial
set of scripts to drive the windows cmake build including obtaining
common prereqs?

I believe I have seen 1 or two batch oriented ones that I'd just as
well avoid 'cept for hints about how to do it in bash/cygwin.

Thanks!

-- 
Eric Covener
cove...@gmail.com

Re: "Most Popular Web Server?"

[Jim Jagielski]

++1

> On Apr 19, 2018, at 6:09 AM, Graham Leggett  wrote:
> 
> On 18 Apr 2018, at 10:46 PM, Mark Blackman  wrote:
> 
>> Is most popular the right thing to aim for? I would advise continuing to 
>> trade on Apache’s current strengths (versatility and documentation for me 
>> and relative stability) and let the chips fall where they may. It’s an open 
>> source project with a massive first-mover advantage and no investors to 
>> please. Just do the right thing, stay visible and the rest will sort itself 
>> out.
> 
> I agree strongly with this.
> 
> I took a look at nginx and gave it a fair evaluation, then I discovered this:
> 
> https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
> 
> with most specifically this:
> 
> "Anything else may possibly cause unpredictable behaviour, including 
> potential SIGSEGV.”
> 
> Both this document and the idea that SIGSEGV would remain unfixed would never 
> fly at Apache. Nginx suffers the problem in that product managers have to 
> trade off the pressure of new features for the marketing people over the need 
> to fix problems they already have. This isn’t sustainable for them.
> 
> We have no such pressure - we release when it’s ready, not because some 
> product manager made promises that their budget couldn’t keep.
> 
> The strength of httpd is that it is a tank - it just keeps going and going. 
> You can deploy it and completely forget about it, it just works. This frees 
> up our users to focus their attention on doing whatever it is they want to do.
> 
> Regards,
> Graham
> —
> 

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Graham Leggett]

On 19 Apr 2018, at 11:57 AM, Joe Orton  wrote:

> Feel like I should drop 2c in here...
> 
> I'd be VERY happy to see more frequent "major" version bumps, i.e. 
> 2.4->2.6->2.8 or whatever which break backwards compat/ABI.  We have the 
> chance to break compat every ~6 months in Fedora so it's no problem 
> getting new code into the hands of users.

As an end user of the software I would hate that.

I love the fact that I can drop httpd v2.4.latest as published by ASF onto a 
RHEL machine and it “just works”. No recompiling modules to a new ABI, 
particularly large modules with large ecosystems, no mess, no fuss. No 
discovery that to get feature X I need to upgrade through two major versions 
along with the dependency hell that results to get there.

I get it that this convenience comes at a price - Redhat is doing work that I 
would otherwise do, but then that’s what I’m paying Redhat for.

That said - yes, we should work to release v2.6.x. Just not every six months.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: "Most Popular Web Server?"

[Graham Leggett]

On 18 Apr 2018, at 8:32 PM, William A Rowe Jr  wrote:

>> You seem to be making a mountain out of a molehill [...]
> 
> 
> Both statements attack not the technical question, but the questioner.
> Please mind your framing.

The expression “making a mountain out of a molehill” means that you’re 
overstating your case - the problem you describe isn’t as bad as you are making 
it out to be. This directly refers to the technical question, not to you 
personally.

I suspect a lot of this comes from the Windows centric approach. In the unix 
world, software distribution and patch management is a first class feature of 
all the major distributions, and our approach and the unix world align very 
well. Windows however hides away their patch management inside the Microsoft 
organisation (as I see it), and leaves a lot of the problem to be solved by 
Windows maintainers from first principles. It is easy to take a look at the 
Windows world and go “this is hard”, but this is simply a function of the 
Windows ecosystem[1]. The problems you describe don’t seem to be anywhere near 
as serious in the unix world as you’re making them out to be.

[1] That said, has the Windows ecosystem moved on to make package deployment 
and patch management easier? Installing Edge from powershell was a 
one-line-cut-and-paste no brainer for me recently, can we / are we taking 
advantage of that?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: "Most Popular Web Server?"

[Dirk-Willem van Gulik]

On 19 Apr 2018, at 12:09, Graham Leggett  wrote:
> On 18 Apr 2018, at 10:46 PM, Mark Blackman  wrote:
> 
>> Is most popular the right thing to aim for? I would advise continuing to 
>> trade on Apache’s current strengths (versatility and documentation for me 
>> and relative stability) and let the chips fall where they may. It’s an open 
>> source project with a massive first-mover advantage and no investors to 
>> please. Just do the right thing, stay visible and the rest will sort itself 
>> out.
> 
> I agree strongly with this. I took a look at nginx and gave it a fair 
> evaluation, then I discovered this:
> ..
> "Anything else may possibly cause unpredictable behaviour, including 
> potential SIGSEGV.”
> 
> Both this document and the idea that SIGSEGV would remain unfixed would never 
> fly at Apache. Nginx suffers the problem in that product managers have to 
> trade off the pressure of new features for the marketing people over the need 
> to fix problems they already have. This isn’t sustainable for them.
..
> The strength of httpd is that it is a tank - it just keeps going and going. 
> You can deploy it and completely forget about it, it just works. This frees 
> up our users to focus their attention on doing whatever it is they want to do.

Large crude oil tankers and formula 1 racing cars are both things that can go 
from A to B. Yet they have different qualities. 

Perhaps we need to emphasise this a bit more - that there is room for different 
things in this market. 

I’ve found the same in production - nginx can be wonderfully fast in certain 
settings - but can also be a relatively fragile and finicky beast best ran in 
serious loadbalancing/failover.

Dw.

Re: "Most Popular Web Server?"

[Graham Leggett]

On 18 Apr 2018, at 10:46 PM, Mark Blackman  wrote:

> Is most popular the right thing to aim for? I would advise continuing to 
> trade on Apache’s current strengths (versatility and documentation for me and 
> relative stability) and let the chips fall where they may. It’s an open 
> source project with a massive first-mover advantage and no investors to 
> please. Just do the right thing, stay visible and the rest will sort itself 
> out.

I agree strongly with this.

I took a look at nginx and gave it a fair evaluation, then I discovered this:

https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/

with most specifically this:

"Anything else may possibly cause unpredictable behaviour, including potential 
SIGSEGV.”

Both this document and the idea that SIGSEGV would remain unfixed would never 
fly at Apache. Nginx suffers the problem in that product managers have to trade 
off the pressure of new features for the marketing people over the need to fix 
problems they already have. This isn’t sustainable for them.

We have no such pressure - we release when it’s ready, not because some product 
manager made promises that their budget couldn’t keep.

The strength of httpd is that it is a tank - it just keeps going and going. You 
can deploy it and completely forget about it, it just works. This frees up our 
users to focus their attention on doing whatever it is they want to do.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Joe Orton]

Feel like I should drop 2c in here...

I'd be VERY happy to see more frequent "major" version bumps, i.e. 
2.4->2.6->2.8 or whatever which break backwards compat/ABI.  We have the 
chance to break compat every ~6 months in Fedora so it's no problem 
getting new code into the hands of users.

I've spent much of my upstream time this year trying to get all RHEL7 
httpd features backported to 2.4.x and have only made it about 90% 
of the way (some big chunks like mod_systemd, suexec stuff remain); 
would love to not have to burn more time on backports because that stuff 
is in 2.6.0 already.

At the moment I think we have to accept that 2.4.x is going to be a bit 
unstable if we're trying to backport everything without *either* having 
good test coverage (which we don't) or having new code widely tested by 
users.

Regards, Joe

Re: "Most Popular Web Server?"

[Nick Kew]

> On 19 Apr 2018, at 10:14, Luca Toscano  wrote:
> 
> Hi Nick,

[chop]

Thanks.  Good reply.  Your suggestions make a lot of sense to me: I just 
wouldn’t
have put them in the context of marketing or evangelism.

Trouble is, it’s relatively few of us who ever get inspired to write about 
things.
Honourable exception being Rich writing docs and books for longer than anyone
can remember!  I think the last person to write serious developer documentation
was Humbedooh, whose work you deservedly praise:

> Ideally the quality bar that I would love to have across our dev docs is this 
> one http://httpd.apache.org/docs/trunk/developer/modguide.html, but in my 
> opinion there is still a a lot of work to do :)

If you want to get writing at a serious level, that’ll be great!  I might even 
contribute
if you can get some momentum going, but I’d never attempt to take a lead, not
least because potential conflict-of-interest with my publisher’s copyright.

— 
Nick Kew

Re: 2.4.3x regression w/SSL vhost configs

[Joe Orton]

Thanks to everyone who followed through :)

For completion, I pushed this to trunk in r1829513 though arguably we 
could/should accept some behavioural change here in 2.5.  No strong 
opinion on this really.  2.4 backport also proposed.

It bugs me to be left with the "surprising" behaviour of ssl_hook_Fixup 
discovered here - it still thinks SSL is disabled for an active SSL 
connection only because of sc->enabled. We could fix that by having that 
function ignore sc->enabled and treat a non-NULL sslconn->ssl as 
sufficient proof the connection uses SSL.  Related issue in PR 61519.

Possibly also we could do something like SSL_get_state(sslconn->ssl) to 
check that a connection is actually negotiated.  I'm not at all 
confident that the existence of sslconn->ssl is a *good* indicator that 
the connection is using SSL, and it might do the wrong thing in some 
edge case.  (I managed to re-introduce CVE-2005-3357 briefly when 
fiddling with this code, so, there are definitely dragons here)

trunk equiv e.g.

Index: modules/ssl/ssl_util.c
===
--- modules/ssl/ssl_util.c  (revision 1829263)
+++ modules/ssl/ssl_util.c  (working copy)
@@ -109,7 +109,7 @@
 sslconn = myConnConfig(r->connection->master);
 }
 
-if (sc->enabled == SSL_ENABLED_FALSE || !sslconn || !sslconn->ssl)
+if (!sslconn || !sslconn->ssl)
 return 0;
 
 if (scout) *scout = sslconn;

Re: "Most Popular Web Server?"

[Luca Toscano]

Hi Nick,

2018-04-19 10:33 GMT+02:00 Nick Kew :

>
> > On 18 Apr 2018, at 20:00, Luca Toscano  wrote:
> >
> > Before joining the httpd project as contributor I struggled to find good
> technical sources about how the httpd internals work,
>
> Likewise.  That’s kind-of what motivated me to start writing about it.
>

And I remember reading your book 2/3 times when I wrote my first module at
work, so thanks a lot :)

But that’s not to say it’s any worse than other software projects I’ve
> encountered over the years.
> There’s always a learning curve, and a struggle to find relevant docs.
> OK, things have improved
> a lot since “just google it” became an option, but information still needs
> unearthing.
>
> Are you suggesting httpd is somehow *worse* than other software you’ve
> hacked in terms of
> developer documentation?  In my experience it’s actually a lot better than
> most, due primarily to
> the high standard of API docs in /include/ and in APR, and of course open
> and searchable source.


I agree that we have a good code documentation, what we miss in my opinion
is a high level (but detailed and with examples) up to date overview of how
things stitch together when a request is processed. I can give you a recent
example from my experience, namely
https://bz.apache.org/bugzilla/show_bug.cgi?id=61860. Eric patiently helped
me to track down how the response flows through the output filters (ending
up in a error response eventually), that helped me a lot to understand more
how things works. And it is of course a super simple example for most of
the experienced httpd's devs, but for people like me that are still very
n00b (and ramping up!) this knowledge is a real treasure that makes the
difference between hours of frustration (ending up nowhere) and the same
time spent in coming up with working patches and contribution for the
project.

http://httpd.apache.org/docs/trunk/developer/API.html is a good example
about something that is a "bit" old but still interesting and helpful. The
same up to date thing for 2.4 could be really valuable for anybody that
joins the project (or thinks to do so).

http://httpd.apache.org/docs/trunk/developer/filters.html is great but it
misses examples in my opinion. I recently discovered for example the
.gbdinit goodies that we ship, they could be a straightforward tool to come
up with real data in the docs for a simple debug of a request/response.

Ideally the quality bar that I would love to have across our dev docs is
this one http://httpd.apache.org/docs/trunk/developer/modguide.html, but in
my opinion there is still a a lot of work to do :)


> > My point is: blogging is fine, but before even starting that I'd focus
> on dumping everybody's knowledge in sections of the docs like
> http://httpd.apache.org/docs/trunk/developer. It is boring and less fun
> than writing C code for sure, but I bet that a ton of people would enjoy
> details about how things work. It will be easier for people to spot "liars"
> in the web that focus their marketing strategy only on how httpd is "old"
> and not performant too..
>
> I’ve called out “liars” once or twice.  Or more usually, purveyors of
> “cargo-cult” whose idea
> of Apache is rooted in how things haven’t been since 1997 or so.  But I’m
> not sure they’re
> really the issue.  nginx has risen primarily because it’s a genuine
> solution, and secondarily
> because it’s had the evangelical community that goes with a challenger
> against an
> incumbent.  Now that it’s risen to be a competitor on more equal terms,
> the evangelism
> still has momentum.  Insofar as we care about market share, we could
> respond in kind,
> preferably avoiding the wilder fringe.
>

I think that nginx has risen because it is a great tool, and I like the
fact that there are more "competitors" that challenge the status quo. What
I don't like is when projects that were born standing on the shoulders of
giants focus their marketing on discrediting others to gain popularity.
Without clear docs that can allow anybody to verify what is true and what
not, the end result is a ton of FUD as we are seeing. I would start with
improving our dev docs and spread the word via social media (tweets,
medium, etc..).

Luca

Re: "Most Popular Web Server?"

[Nick Kew]

> On 18 Apr 2018, at 20:00, Luca Toscano  wrote:
> 
> Before joining the httpd project as contributor I struggled to find good 
> technical sources about how the httpd internals work,

Likewise.  That’s kind-of what motivated me to start writing about it.

But that’s not to say it’s any worse than other software projects I’ve 
encountered over the years.
There’s always a learning curve, and a struggle to find relevant docs.  OK, 
things have improved
a lot since “just google it” became an option, but information still needs 
unearthing.

Are you suggesting httpd is somehow *worse* than other software you’ve hacked 
in terms of
developer documentation?  In my experience it’s actually a lot better than 
most, due primarily to
the high standard of API docs in /include/ and in APR, and of course open and 
searchable source.
The contrast is closed source software, where docs inevitably diverge badly 
from reality.
I’ve mused about this in the past: for example
https://bahumbug.wordpress.com/2006/11/06/the-documentation-gap/
https://bahumbug.wordpress.com/2008/09/16/security-by-cookery/

> My point is: blogging is fine, but before even starting that I'd focus on 
> dumping everybody's knowledge in sections of the docs like 
> http://httpd.apache.org/docs/trunk/developer. It is boring and less fun than 
> writing C code for sure, but I bet that a ton of people would enjoy details 
> about how things work. It will be easier for people to spot "liars" in the 
> web that focus their marketing strategy only on how httpd is "old" and not 
> performant too..

I’ve called out “liars” once or twice.  Or more usually, purveyors of 
“cargo-cult” whose idea
of Apache is rooted in how things haven’t been since 1997 or so.  But I’m not 
sure they’re
really the issue.  nginx has risen primarily because it’s a genuine solution, 
and secondarily
because it’s had the evangelical community that goes with a challenger against 
an
incumbent.  Now that it’s risen to be a competitor on more equal terms, the 
evangelism
still has momentum.  Insofar as we care about market share, we could respond in 
kind,
preferably avoiding the wilder fringe.

— 
Nick Kew

AW: "Most Popular Web Server?"

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Daniel Ruggeri [mailto:drugg...@primary.net]
> Gesendet: Donnerstag, 19. April 2018 02:22
> An: dev@httpd.apache.org
> Betreff: Re: "Most Popular Web Server?"
> 
> On 4/18/2018 11:46 AM, Jim Jagielski wrote:
> 
> > Personally, I'd like to see the the PMC take a more active and
> > direct role in addressing #1, maybe w/ monthly blog posts
> > coordinated w/ Sally. It would also be cool to reboot Apache Week
> > (I know it was an external, 3rd party effort) in in conjunction
> > w/ the blog posts or instead of it.
> 
> This is interesting. Can you provide some examples for the types of blog
> posts that you think would be good to make? Stealing from other parts of
> the thread (thanks, Luca!), I could see value in providing bite-sized
> tidbits of how requests/responses are run, what this whole "hook" and
> "pool" stuff is all about and anything to demystify the filter chain.
> Those things could also be used to refresh our developer guidelines
> pages.
> I'm not positive that kind of content is what you have in mind since I
> think that would primarily drive the interest of module authors rather
> than the folks who choose which webserver to use.

Just a quick thought that comes to my mind. I know that there are excellent
presentations at ApacheCon's on various of such topics. Would it be possible
to store / link the slides (need probably be contributed by the authors) and / 
or
videos of the sessions on our website?

Regards

Rüdiger

AW: /scheme/i sensitivity? (was: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch)

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Mittwoch, 18. April 2018 18:49
> An: httpd 
> Betreff: /scheme/i sensitivity? (was: svn commit: r1829430 -
> /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch)
> 
> On Wed, Apr 18, 2018 at 11:36 AM, Jim Riggs  wrote:
> > Fair enough. I'm fine standardizing either way. strn?cmp() is probably
> more "correct". As it stands, though, the check in core is not actually
> checking everything that log.c will handle.
> 
> There are a number of places where we have "scheme:resource"-style
> resources throughout httpd. Especially mod_ssl.
> 
> Do we want to make a group commitment to strn?casecmp() all of
> these cases in any 2.next/3.0 release?

strn?casecmp() on the scheme part? I guess this would make sense.

Regards

Rüdiger