Date: Fri, 11 Apr 2014 15:01:33 -0400 From: Julio Merino <jmmv@freebsd.org> To: "Peel, Casey" <casey.peel@isilon.com> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>, "bdrewery@FreeBSD.org" <bdrewery@FreeBSD.org> Subject: Re: Please provide process for small, targeted fixes in tools/regression Message-ID: <5F1D5D49-5F39-4EAC-89D5-E4D10FB3B01E@freebsd.org> In-Reply-To: <16437CC5729B5345AF77F816513376E820BAF854@MX103CL02.corp.emc.com> References: <16437CC5729B5345AF77F816513376E820BAF854@MX103CL02.corp.emc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Casey, On Apr 11, 2014, at 13:56, Peel, Casey <casey.peel@isilon.com> wrote: > I have several small, targted fixes to files in src/tools/regression/ = to: >=20 > 1) enable existing *.t tests to run that were failing This is not "too hard" but is certainly tricky. I did a bunch of them about a month ago but didn't write a lot of = documentation on the topic. You can find some useful notes in = http://goo.gl/rWpdDR though, which includes slides and accompanying = notes for the tutorial I gave at AsiaBSDCon. Most of that ought to be = converted to actual documentation of course. The very first step, which is arguably the hardest, is to get the tests = to work while running them with the prove(1) tool. This has several = implications (an important one being that any testing logic must be = removed from the Makefile). > 2) add new *.t files for directories that enable running = TAP-enabled binaries through prove That's good as a second step. I suspect these new *.t files will just = invoke another script (the actual test), which means the .t files will = be removed when the tests are hooked into the test suite. But that's = fine: it's better to get them running with prove(1) first because then = the move is simple enough. > 3) *.c updates to remove clang compiler warnings Yes please. Once the tests run with prove(1) and pass, we can bundle them into the = test suite. This roughly involves moving the code to corresponding = 'tests/' subdirectories, writing Makefiles and updating the mtree. = Mostly mechanical (but very annoying when the tests provide tons of data = files; see usr.bin/make/tests/). > Can someone please provide a process for getting these approved and = committed in a timely manner? I would prefer to get these upstream and = then pull them down if at all possible, but I simply don't have time for = these to languish for weeks in a committee. >=20 > Isilon has BSD committers (eg: bdrewery) I can leverage if that would = be more expedient but given these are all testing-centric it seems like = getting approval from one or more people on freebsd-testing would be = best. If you can get self-contained diffs, I can try to get them in for you = (but can't make any promises as my time for FreeBSD varies significantly = week to week...) For simplicity of review, I'd appreciate at least one patch for every = subdirectory within tools/regression/foo/bar/ with at least one patch to = get the first tests up and running first with prove(1). More patches = are better! The move of the fixed tests to the new infrastructure (aka the = boilerplate work) is something I may be able to help with.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5F1D5D49-5F39-4EAC-89D5-E4D10FB3B01E>