Hi Ken,
----- Original Message -----
> > > for different PCP versions. However, I've found several
> > > of the tests to have *deep* knowledge of internals of PCP,
> > > and they can break in non-intuitive ways when the planets
> > > are not aligned.
> >
> > Because PCP follows a fundamentally a client-server architecture it
> > is absolutely critical that the QA components are _not_ exposed to
> > version
> > dependencies but rather accommodate version differences so that
> > cross-version inter-operation can be tested, e.g. new clients with
> > old pmcd and vice versa.
>
> Right. We're definitely on the same page there. This always was the
> case (even before, when pcp and pcpqa were one and the same tree),
> and I'm 100% agreeing this must remain the case.
>
> But there's another problem ...
So, I'm plowing ahead with setting up these package builds. I merged
in the pcp-gui packaging changes earlier today, which now produces a
pcp-gui-testsuite packages (deb/rpm). All seemed to go fairly well,
and actually there's at least one genuine failure in there (027) which
we've missed thanks to pcp-gui being a bit forgotten about of late.
Since its you and I who do most of the pcpqa work at the moment anyway
I think we can go ahead with a merge, keeping in mind version issues.
It is still possible to run in-tree QA of course and for different PCP
versions locally if need be.
To that end, I'll begin merging pcpqa back into pcp/qa in the main PCP
tree shortly, in order to keep the packaging moving forward. I think
we'll still have some fine-tuning to do around whether sources need to
be in the binary package (rpmlint will complain at least), and once we
have something concrete we can make further informed decisions. If it
all turns out to be a horrible nightmare (?!), we can always undo it.
cheers.
--
Nathan
|