Re: Concurrency testing

On Wed, Oct 7, 2009 at 6:01 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Oct 7, 2009 at 8:33 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
>>> Do we need to restrict ourselves to core?  Developers already need
>>> flex and bison, which aren't needed when installing from the tarball.
>>> Couldn't we also have "make dev-check" that has higher requirements
>>> than "make check" does, but does a more thorough job?
>>
>> flex and bison are not Perl modules.
>
> True, but so what?

Right, my point was only that we already have different levels of
requirements for different things.

>
> I don't really see what's wrong with using Perl modules that are
> likely to be installed most places and easy to obtain where not, if it
> makes writing a test framework much easier.  But I also think that we
> should not get bogged down on exactly which tools to use - it seems to
> me the first thing is to find someone who is willing to do the work.
> If someone makes an AWESOME test suite that uses a module which is a
> little too adventurous, we can probably find a way of adjusting it
> after the fact so as to remove the dependency (I fancy myself fairly
> good at this sort of thing, where Perl is concerned).  But if we argue
> about tools now, we're just going to discourage anyone from taking a
> stab at it.

OK, but what would we be taking a stab at? Would it simply be
something like "make dev-check" or "make concurrency-check", which
the build farm would then just invoke, thereby killing two birds with
one stone? Or would it have to be something fancier than just that?
Or am I already too lost in the details?

Jeff