On Thu, 2002-09-26 at 09:43, Alan Hoyt wrote:
> Yes, this is rather problematic.
>
> Not having seen the code, I am flying blind here - but wouldnt large
> portions of the QA code base be relatively constant/stable?
>
> Couldn't most of the hard coded dependencies be abstracted into
> configuration/initialization files to minimize architectural
> /topological dependencies?
>
> In other words, could we substantially reduce the gatekeeper load
> through well conceived code changes/clean ups (sounds like a catch 22)?
>
> If not, the simplest solution would be to release PCP along with the QA
> scripts that were used to validate it (i.e. without accepting QA script
> patches). At least the community would have tools to exhaustively verify
> PCP changes before they were submitted/deployed.
>
> Possibly, you could monitor QA script changes made by the community and
> determine (at that time) whether there is any benefit for SGI to
> incorporate those changes.
>
I suspect that its a great deal like renovating houses, at some point
the renovations become so massive and complex that its just easier to
tear it down and start from scratch.
I believe the easiest and best way to approach this is to have bribe Ken
(and Co.) to write a small document that would outline the steps to
creating a PCP test base and what actually constitutes effective PCP QA
(what!?!?! "it compiles" doesn't count? ;-)). Once the community has an
idea of where to start, then its a matter of mapping out areas for
interested people to focus on. Perhaps, if things go well, Ken can throw
some tests over the wall to be added, not to mention he could
incorporate some of the open source tests. I suspect, based on personal
experience, that Ken already has a very clear idea of how it would be
structured and its a matter of getting it down on paper.
Of course I am in no position to volunteer Ken for anything. ;-)
-Dean
|