Why indeed. No reason I know of, QA (quality assurance) was the term used for testing on the pcp project from day 1 .... blame Ken, I guess. I could go with "tests" ... may make it easier to merge, b
Nathan, You and I had already talked on IRC about many of these points. I think we're in agreement on all the other points. I'm not convinced that moving pcpqa back into the PCP tree is a good idea.
Nathan, thanks for picking up the baton here. There is a multiple sense of deja vu here. Like company reorgs, changing the pcp packaging is one of those things that happens in a cyclic fashion and th
General *nod* to all of the above. My main sticking point is pmdumptext. I want to have kmdumptext become pmdumptext, and have all C++ code in one place using the one library instead of dup'ing this.
Nathan Scott wrote: On Wed, 2009-02-04 at 07:27 +1100, Ken McDonell wrote: ... Renaming kmchart -> pmchart and kmtime -> pmtime is fine if the sgi proprietary pieces are cremated. The original pmchar
Also, I've been reworking the PCP web pages recently, for several reasons: - simplify - modernify - de-purplify - document the new packaging layout - introduce the new "PCP Glider" project - make it
Nathan Scott wrote: On Wed, 2009-02-04 at 11:14 +1100, Mark Goodwin wrote: So, to sum up my current thinking: ... There's some new content (started on the online man pages, added some docs about PCP
Done. May as well be consistent - can you make it dev? There should be (already) a stable tree there also... did that survive the cloning process? Oh, also be a good idea to check with Russell/Eric c
I left the default branch named 'master' rather than renaming it to 'dev' like we have in the pcp tree. Let me know what you'd rather. May as well be consistent - can you make it dev? There should be
nscott> - Renaming kmchart/kmtime -> pmchart/pmtime is fine with me. I nscott> will keep symlinks for backward compatibility, etc. Unless you plan to provide bug-to-bug compatibility between kmchart
kmchart provides pretty much the same command line options (it is platform independent, so deep-voodoo Xresource stuff isn't going to work) - but the options used were all based on either standard PC
Yes, its for "Ken". kmchart/kmtime don't use any KDE libraries, and has no code specific to that particular desktop (does happen to build on the same Qt libraries, but thats coincidental AFAIK). chee
The same users who we might be "helping" by not using a pmchart name, will just get left out in the no-pmchart-for-you cold, when SGI stops shipping the old one. So, I'm comfortable having a single p
MG> BTW, Max, which bug-for-bugs in pmchart are you thinking of? MG> pmchart doesn't have any bugs ;-) Ok, WARs like counter-wrap detection in the fetchgroup code, GIF generation (can kmchart do that
It honours PCP_COUNTER_WRAP, if thats what you mean? How many of the last-of-the-mohicans^Wpmcharticans do you really think rely on some particular counter-wrap handling anyway? kmchart^WThe new pmch
NS> It honours PCP_COUNTER_WRAP, if thats what you mean? It was more then PCP_COUNTER_WRAP - I've had to fix a bug with gif generation (I think sometime around 2007) for people who do things which go
Yes. Layout from the command line is very similar between the two. The worst part of the km* naming scheme is it was fine for just one binary, then kmtime came along, then kmquery, then dumptext got
Nathan Scott wrote: ps: Fedora10 has changed rpm options/syntax/configs/... & the pcp/pcp-gui Makepkgs is b0rked - any interest in having a look, Max? You know this stuff better than anyone (Ken said