Please provide process for small, targeted fixes in tools/regression

[Julio Merino]

Hello Casey,

On Apr 11, 2014, at 13:56, Peel, Casey <casey.peel at isilon.com> wrote:

> I have several small, targted fixes to files in src/tools/regression/ to:
> 
> 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.
> 
> 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.