pcp
[Top] [All Lists]

Re: [pcp] NSS/NSPR review notes

To: Dave Brolley <brolley@xxxxxxxxxx>
Subject: Re: [pcp] NSS/NSPR review notes
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 30 Aug 2012 18:58:56 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
In-reply-to: <503FB5BB.6060002@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
----- Original Message -----
> Hi Nathan,
> 
> Wow, thanks for the merge and for the good catches while doing it!

No problem.  Again - struck me that good progress auditing all call
sites and plugging in the NSS variants being made; alot of work went
in there, glad someone else did it all.  :)  There were no other new
QA failures (theres a handful of existing failures I'm still working
my way through).  I'm also not setup for remote tests yet (see below)
which is important for this checking - hence I put it all in a new
"nssmerge" branch for now, so we can work from that starting point,
which is almost ready to merge.

> I have had a look and don't see anything missing. I look forward to
> the full test results. Is it difficult to setup/run the test suite?

Yes and no.  It depends.  Its straight forward to initially setup now
- you can either do a full package build (./Makepkgs) and install the
pcp-testsuite rpm, or run the tests in the $(TOPDIR)/qa directory
directly.  Tricky parts come in when tests fail (initially), finding
out whats gone wrong in setup process, or whether its a genuine test
failure.

I sent some mail a week or so back about the initial steps - there's
ongoing refinements to make it simpler still, so those are already
out-of-date a little.

You can now type "./common" as a first step (previously I suggested
"make setup", but that has a chicken-and-egg situation with getting
the QA agents running locally - pmdasample, etc) before attempting
to create some PCP archives.

Once thats done, you're setup and ready - then its just a matter
of running the "./check" driver script, which will run through all
the tests and provides feedback on each one.

Thats the easy version.  You and I are going to quickly need to go
beyond that though, into full-blooded QA mode, where we have remote
systems involved for doing protocol up/down rev, remote 32/64 bit
host checking, etc.  This is more involved, and requires hostnames
to be added to the qa_hosts files (via qa_hosts.master).

But, get the first phase up and running reliably first before the
attempt on remote tests is made (bound to be some fallout there).

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>