[OpenAFS] buildbot and packages

[Derrick Brashear]

On Mon, Sep 17, 2012 at 1:15 PM, Troy Benjegerdes <hozer@hozed.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-fuse=
-git/tests/fuse/../../src/afsd/afsd.fuse -dynroot -fakestat -d -confdir /ho=
me/hozer/src/openafs-fuse-git/tests/fuse/conf -cachedir /home/hozer/src/ope=
nafs-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=3D0x0000047b
> max_readahead=3D0x00020000
> 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 updates
> as quickly. That unskilled smoke testing and/or automated runs gets a LOT
> 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 simpl=
e
> 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 ma=
ny
>> > 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 he=
re; 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 con=
trol of a fair amount of stuff that random college students won't have.  'm=
ake check' on a single machine will never give you useful testing results o=
ther than to find packaging or "smoke test" errors, which aren't all that h=
elpful 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 hal=
f-
>> > assed, gets distributed? I can't think of much of anything else that h=
as 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 m=
ight otherwise appear. GIGO applies here. A uncoordinated test process is u=
nlikely to produce anything useful in that there have to be a sequence of c=
oordinated 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
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>



--=20
Derrick