[OpenAFS] buildbot and packages

Tue, 18 Sep 2012 00:27:06 -0400

the tests are not ready to be run on the buildslaves. it's been
working toward that point, but not yet.

On Tue, Sep 18, 2012 at 12:08 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
> Nope, Debian x86-64
>
> Any chance the buildbots can be easily modified to run make check/make te=
sts?
>
> I'm really curious what debian ppc32/ppc64 will do. I have an arm build, =
but
> no fuse kernel module (debian on an sdcard on an android tablet).
>
> On Mon, Sep 17, 2012 at 11:39:55PM -0400, Derrick Brashear wrote:
>> So. Were you perchance using it on a Mac? Probably a 64 bit Intel mac?
>>
>> http://gerrit.openafs.org/#change,8132
>>
>> As nearly as I can tell, this is a very specific problem. The code is fi=
ne. The
>> 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
>> bit pointers,
>> because MacOS does something odd with dirent.h
>>
>> On Mon, Sep 17, 2012 at 1:20 PM, Derrick Brashear <shadow@gmail.com> wro=
te:
>> > On Mon, Sep 17, 2012 at 1:15 PM, Troy Benjegerdes <hozer@hozed.org> wr=
ote:
>> >> 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=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 Libtoo=
l,
>> >> and there's a 90% probability it's a 30-second 'aha', followed by a t=
wo
>> >> 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 w=
hat
>> >> that two line fix is, or work in my own isolated fork and not get upd=
ates
>> >> 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 s=
imple
>> >> and meaningful they can do, instead of waiting around for someone els=
e 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 a=
s many
>> >>> > platforms as possible, and getting thousands of bored college stud=
ents to
>> >>> > download, install, and test them?
>> >>>
>> >>> I think that's still overly optimistic. There's a lot of moving part=
s here; you just can't just install a package and have it do something usef=
ul. 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 resul=
ts other than to find packaging or "smoke test" errors, which aren't all th=
at 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 th=
at has a
>> >>> > bigger resource multiplation factor than a 'one click install', al=
ong with some
>> >>> > defaults to use a 'test.openafs.org' cell.
>> >>>
>> >>> As others have commented, unskilled testing performed without a deta=
iled test plan on software systems this complex is probably less helpful th=
an 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
>> >> _______________________________________________
>> >> OpenAFS-info mailing list
>> >> OpenAFS-info@openafs.org
>> >> https://lists.openafs.org/mailman/listinfo/openafs-info
>> >>
>> >
>> >
>> >
>> > --
>> > Derrick
>>
>>
>>
>> --
>> Derrick
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info

--=20
Derrick