[OpenAFS] buildbot and packages
Mon, 17 Sep 2012 23:39:55 -0400
So. Were you perchance using it on a Mac? Probably a 64 bit Intel mac?
As nearly as I can tell, this is a very specific problem. The code is fine.=
circumstances of building afsd.fuse meant it was collateral damage when we
started using roken, but only on MacOS, and probably only for non-32
because MacOS does something odd with dirent.h
On Mon, Sep 17, 2012 at 1:20 PM, Derrick Brashear <email@example.com> wrote:
> On Mon, Sep 17, 2012 at 1:15 PM, Troy Benjegerdes <firstname.lastname@example.org> wrote=
>> 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-fus=
e-git/tests/fuse/../../src/afsd/afsd.fuse -dynroot -fakestat -d -confdir /h=
ome/hozer/src/openafs-fuse-git/tests/fuse/conf -cachedir /home/hozer/src/op=
enafs-fuse-git/tests/fuse/vcache -mountdir /home/hozer/src/openafs-fuse-git=
>> FUSE library version: 2.8.6
>> nullpath_ok: 0
>> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56
>> INIT: 7.17
>> 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.
> I'd bet not. However....
>> 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 update=
>> as quickly. That unskilled smoke testing and/or automated runs gets a LO=
>> of mileage.
> Not really. Build with debugging and get a real backtrace. That said,
> since fuse is not *required*
> functionality in a build, yes, it's undertested. This is why we've
> generally avoided code which doesn't
> always build. Or, at least tried to.
>> It also gives people who want to learn about the codebase something simp=
>> and meaningful they can do, instead of waiting around for someone else t=
>> 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 m=
>>> > platforms as possible, and getting thousands of bored college student=
>>> > download, install, and test them?
>>> I think that's still overly optimistic. There's a lot of moving parts h=
ere; 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 co=
ntrol 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 =
>>> > Wouldn't that massive crowsourced testing effort be worth the time of=
>>> > single developer to make sure *some* sort of package, even if it's ha=
>>> > assed, gets distributed? I can't think of much of anything else that =
>>> > bigger resource multiplation factor than a 'one click install', along=
>>> > defaults to use a 'test.openafs.org' cell.
>>> As others have commented, unskilled testing performed without a detaile=
d 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 ca=
n't see how crowdsourcing would help here.
>>> OpenAFS-info mailing list
>> OpenAFS-info mailing list