> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > Sent: 25 April 2002 11:42
> On Thu, Apr 25, 2002 at 08:31:14AM -0000, [EMAIL PROTECTED] 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). +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. Sander
