Unintended Side Effects (Was: Re: svn commit: r1732275 - in /httpd/httpd/branches/2.4.x: ./ include/ap_mmn.h include/http_connection.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/ssl_engine_kernel.c server/connection.c server/mpm/event/event.c server/scoreboard.c)

[Jim Jagielski <ji...@jaguNET.com>]

We should always ensure that when we fix something, or
when we add something, we don't change the current behavior
of httpd in an unintended way. This rev is a great example of
that. The clearing of those scoreboard slots is completely
unrelated to the actual change itself.

Of course, the "blame" is shared because even if the patch
does change something, it is up to all of us to review it,
not just by running and testing the code, but actually
*inspecting* the patch for what it does.

The very fact that this change made it all the way
thru the backport process to end up in 2.4.x is a reminder
that we all need to stay vigilant.

Re: Unintended Side Effects (Was: Re: svn commit: r1732275 - in /httpd/httpd/branches/2.4.x: ./ include/ap_mmn.h include/http_connection.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/ssl_engine_kernel.c server/connection.c server/mpm/event/event.c server/scoreboard.c)

[Stefan Eissing <st...@greenbytes.de>]

> Am 14.04.2016 um 15:09 schrieb Jim Jagielski <ji...@jaguNET.com>:
> 
> We should always ensure that when we fix something, or
> when we add something, we don't change the current behavior
> of httpd in an unintended way. This rev is a great example of
> that. The clearing of those scoreboard slots is completely
> unrelated to the actual change itself.

Yes, I meant well, but should have known better or at least
asked for confirmation on the list. I have no excuse.

Scoreboard is one of the areas where unwanted changes can slip
through more easily than in other places, as there are no test
cases covering this text output.

Since its functionality is vital for a lot of users, maybe
we should invest into having a formatted, parseable variant
of its output. That we could use in tests.

> Of course, the "blame" is shared because even if the patch
> does change something, it is up to all of us to review it,
> not just by running and testing the code, but actually
> *inspecting* the patch for what it does.
> 
> The very fact that this change made it all the way
> thru the backport process to end up in 2.4.x is a reminder
> that we all need to stay vigilant.

Anything that is not covered by test code will break sooner
or later unless the original, sole author becomes immortal.

That is not meant as an excuse, just an observation.

-Stefan