[OpenAFS] buildbot and packages

[Troy Benjegerdes]

I'm looking to get all the low-hanging fruit with unskilled testing.
Particularly with regressions like this:

hozer@six:~/src/openafs-fuse-git/tests/fuse$ /home/hozer/src/openafs-fuse-git/tests/fuse/../../src/afsd/afsd.fuse -dynroot -fakestat -d -confdir /home/hozer/src/openafs-fuse-git/tests/fuse/conf -cachedir /home/hozer/src/openafs-fuse-git/tests/fuse/vcache -mountdir /home/hozer/src/openafs-fuse-git/tests/fuse/mntdir
FUSE library version: 2.8.6
nullpath_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56
INIT: 7.17
flags=0x0000047b
max_readahead=0x00020000
Starting AFS cache scan...found 0 non-empty cache files (0%).
afsd: All AFS daemons started.
Segmentation fault


I am pretty sure this is related to the work Simon is doing on Libtool,
and there's a 90% probability it's a 30-second 'aha', followed by a two
line fix, and we're back to working again.


The code is so complicated it will take me half a day to track down what
that two line fix is, or work in my own isolated fork and not get updates
as quickly. That unskilled smoke testing and/or automated runs gets a LOT
of mileage.

It also gives people who want to learn about the codebase something simple
and meaningful they can do, instead of waiting around for someone else to
come up with a test plan.


On Mon, Sep 17, 2012 at 11:25:36AM -0500, David Boyes wrote:
> > How about an effort to get nightly builds of master available on as many
> > platforms as possible, and getting thousands of bored college students to
> > download, install, and test them?
> 
> I think that's still overly optimistic. There's a lot of moving parts here; you just can't just install a package and have it do something useful. You need to have a lot of surrounding infrastructure that involves real control of a fair amount of stuff that random college students won't have.  'make check' on a single machine will never give you useful testing results other than to find packaging or "smoke test" errors, which aren't all that helpful overall. 
> 
> > Wouldn't that massive crowsourced testing effort be worth the time of a
> > single developer to make sure *some* sort of package, even if it's half-
> > assed, gets distributed? I can't think of much of anything else that has a
> > bigger resource multiplation factor than a 'one click install', along with some
> > defaults to use a 'test.openafs.org' cell.
> 
> As others have commented, unskilled testing performed without a detailed test plan on software systems this complex is probably less helpful than might otherwise appear. GIGO applies here. A uncoordinated test process is unlikely to produce anything useful in that there have to be a sequence of coordinated tests, replacing one component at a time in a known order. I can't see how crowdsourcing would help here. 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info