httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <>
Subject RE: ab.c versionining was Re: cvs commit: httpd-2.0/support ab.c
Date Thu, 25 Apr 2002 12:36:42 GMT
> From: Justin Erenkrantz []
> Sent: 25 April 2002 11:42

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

+1.  Moving it to httpd-test is probably not a bad idea.  However,
if we do that we should start releasing httpd-test aswell...

> 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

This is a very long email that contains everything I had in mind on
this...  I wont waste any more words and'll just state that I agree.


View raw message