[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-dev
Subject: Re: Log-addressing branch ready for review
From: Stefan Fuhrmann <stefan.fuhrmann () wandisco ! com>
Date: 2013-11-30 14:29:52
Message-ID: CA+t0gk3TmrTr8--2tDY6K0Zcx=rA3Sq6eSVw5zgMqokqbjn7Vg () mail ! gmail ! com
[Download RAW message or body]
On Sat, Nov 30, 2013 at 2:23 PM, Daniel Shahaf <d.s@daniel.shahaf.name>wrote:
> Daniel Shahaf wrote on Sat, Nov 30, 2013 at 15:19:56 +0200:
> > Stefan Fuhrmann wrote on Sat, Nov 30, 2013 at 08:48:30 +0100:
> > > Again, you are missing the point. You are saying that there
> > > are lots of possible configurations and various combinations.
> > > I'm saying that we *are* actually able to test many variants.
> > > One simply needs to update their overall test script.
> >
> > There are classes of problems that our test suite simply isn't designed
> > to catch.
> >
> > For example:
> >
> > - We won't catch 'premature kill -9' bugs (r1494298)
> > - We won't catch concurrency bugs (r1302613)
>
> As another example, we have architectue-dependent code, for example
> the definition of SVN_UNALIGNED_ACCESS_IS_OK. In those cases, do we
> test the "unlikely" branch (eg: SVN_UNALIGNED_ACCESS_IS_OK=0) too?
>
Well, that is exactly the kind of things that a test script
should cover. Running just another combination of config
options add less than 2:30 total (or 2 minutes with ra_local).
So, being able to quickly run a great number of variants
is clearly useful here.
> My build script defines -DSVN_UNALIGNED_ACCESS_IS_OK=0 for precisely
> this reason.
>
I think we should make a list of combinations that should
be part of release testing. It is certainly a waste to do
something like
[local, serf, svn] x [bdb, fsfs, fsx] x [1.0 .. 1.9] x [P(config options)]
Instead, maybe along the lines of:
[local, serf, svn] x [bdb, fsfs, fsx] x [1.9] x [config defaults]
[local, serf or svn] x [fsfs] x [1.9] x [Selected config option sets]
[local, serf or svn] x [fsfs] x [1.1 .. 1.9] x [config defaults]
[local, serf or svn] x [bdb] x [1.0] x [config defaults]
For the ra layer bit, I feel that having "all in one" and
"separate c/s" may trigger different failure scenarios.
BDB is deprecated and FSX is experimental, so let's
focus on FSFS for the non-standard setups. 1.9 should
cover the most code making it a good test bed for
config option variation. At least the standard config
should work with all format versions.
Makes sense? What combinations of config options
should we test?
-- Stefan^2.
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 30, 2013 \
at 2:23 PM, Daniel Shahaf <span dir="ltr"><<a href="mailto:d.s@daniel.shahaf.name" \
target="_blank">d.s@daniel.shahaf.name</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Daniel Shahaf wrote on Sat, Nov 30, 2013 at \
15:19:56 +0200:<br> <div class="im">> Stefan Fuhrmann wrote on Sat, Nov 30, 2013 \
at 08:48:30 +0100:<br> > > Again, you are missing the point. You are saying \
that there<br> > > are lots of possible configurations and various \
combinations.<br> > > I'm saying that we *are* actually able to test many \
variants.<br> > > One simply needs to update their overall test script.<br>
><br>
> There are classes of problems that our test suite simply isn't designed<br>
> to catch.<br>
><br>
> For example:<br>
><br>
> - We won't catch 'premature kill -9' bugs (r1494298)<br>
> - We won't catch concurrency bugs (r1302613)<br>
<br>
</div>As another example, we have architectue-dependent code, for example<br>
the definition of SVN_UNALIGNED_ACCESS_IS_OK. In those cases, do we<br>
test the "unlikely" branch (eg: SVN_UNALIGNED_ACCESS_IS_OK=0) \
too?<br></blockquote><div><br></div><div>Well, that is exactly the kind of things \
that a test script<br></div><div>should cover. Running just another combination of \
config<br> options add less than 2:30 total (or 2 minutes with \
ra_local).<br></div><div>So, being able to quickly run a great number of \
variants<br></div><div>is clearly useful here.<br></div><div> <br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
My build script defines -DSVN_UNALIGNED_ACCESS_IS_OK=0 for precisely<br>
this reason.<br>
</blockquote></div><br></div><div class="gmail_extra">I think we should make a list \
of combinations that should<br>be part of release testing. It is certainly a waste to \
do<br>something like<br><br></div><div class="gmail_extra"> [local, serf, svn] x \
[bdb, fsfs, fsx] x [1.0 .. 1.9] x [P(config options)]<br><br></div><div \
class="gmail_extra">Instead, maybe along the lines of:<br><br>[local, serf, svn] x \
[bdb, fsfs, fsx] x [1.9] x [config defaults]<br> [local, serf or svn] x [fsfs] x \
[1.9] x [Selected config option sets]<br>[local, serf or svn] x [fsfs] x [1.1 .. 1.9] \
x [config defaults]<br></div><div class="gmail_extra">[local, serf or svn] x [bdb] x \
[1.0] x [config defaults]<br> <br>For the ra layer bit, I feel that having "all \
in one" and<br></div><div class="gmail_extra">"separate c/s" may \
trigger different failure scenarios.<br></div><div class="gmail_extra">BDB is \
deprecated and FSX is experimental, so let's<br> </div><div \
class="gmail_extra">focus on FSFS for the non-standard setups. 1.9 should<br>cover \
the most code making it a good test bed for<br></div><div class="gmail_extra">config \
option variation. At least the standard config<br> should work with all format \
versions.<br><br></div><div class="gmail_extra">Makes sense? What combinations of \
config options<br>should we test?<br><br></div><div class="gmail_extra">-- \
Stefan^2.<br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic