httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c
Date Thu, 25 Apr 2002 09:41:33 GMT
On Thu, Apr 25, 2002 at 08:31:14AM -0000, wrote:
> dirkx       02/04/25 01:31:14
>   Modified:    support  ab.c
>   Log:
>   During the 1.3->2.0 migragrion; ab its #defined VERSION own string was replaced
>   by that of the base server distribution it sits in. Propably by accident.
>   This is propably not a good idea - as ideally one would like to be able to compare
>   ab runs as much as possible - even across releases of apache 2.0 - assuming ab or
>   the dependent APR has not changed (note to self: we do not track APR in our version
>   structure). This commit decouples the version strings for now. Though the actual
>   value may be nicely confusing.

If ab has a different versioning system than everything else in
our tree, then, I believe we should consider removing it from
httpd-2.0 - perhaps into httpd-test.  If it is in the httpd-2.0
tree, then I think it should follow the versioning conventions of
the rest of the code (i.e. what was there before this commit
minus the RCS ID).

We recently changed mod_ssl to mimic httpd-2.0's version rather
than report an unrelated version.  This should help us with any
bug reports.  If ab 2.0.36-dev2 were included in 2.0.36, 2.0.37,
and 2.0.38, we have no idea where it came from.  By linking the
version to the httpd it was bundled with, it gives us (IMHO) an
idea of when it was compiled.  As we do with any -dev version of
httpd, we do not trust any bug reports on -dev suffix builds.
If ab's version has a -dev suffix, we shouldn't trust its results.

Having it separated out like you have just changed it to is going
to cause lots of problems for us maintaining it.  While your
suggestion to bump the version number of ab whenever a change is
made to APR that might effect ab is a nice sentiment, it isn't
realistic, IMHO.  There are lots of unintended side effects -
if I optimize the select() call in APR for incomplete writes
(something that has been occurring recently, but isn't complete
on all platforms I believe), do I now need to bump ab.c's version?
Like our MMN, what if I make a mistake?  Or, what if the bump isn't
needed on every platform?  We obviously wouldn't be bumping APR's
version on such a fix.  (Let's not even think about compiling the
same version of APR but with threads and without thread safety.)

By linking ab's version to its bundled httpd's version (which implies
its APR version), we have gained knowledge of its surrounding
environment.  I believe that is a far better situation than trying
to manage ab's version independently.  

I believe long-term comparisons can only be done with the same
test-tool binary.  If you attempt to take results generated from two
different binaries (esp. ones with different maturity levels in its
support libraries or with different machines) and compare their
results, you may have invalidated your test.  -- justin

View raw message