On Wed, Oct 7, 2009 at 6:01 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Oct 7, 2009 at 8:33 PM, David E. Wheeler <da...@kineticode.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers