pcp
[Top] [All Lists]

Re: [pcp] Source and binary packaging - future directions

To: Nathan Scott <nscott@xxxxxxxxxx>
Subject: Re: [pcp] Source and binary packaging - future directions
From: Kevin Wang <kjw@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2009 18:23:40 -0800
Cc: pcp@xxxxxxxxxxx
In-reply-to: <1233627045.5518.55.camel@xxxxxxxxxxxxxxxxxx>
References: <1233627045.5518.55.camel@xxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.11
 From Nathan Scott
> Toward the end of last year, the good folk at SGI asked whether
> we could make kmchart more a part of PCP.  In particular, there
> was discussion of whether there should be one source tree, and
> using the same naming convention as the other PCP tools.
> 
> With the pending release of additional (SGI) monitoring tools,
> it would be good to have these issues sorted out, so there is
> clarity on where that code should end up in the oss releases.
> 
> I'd like to solicit input before I go ahead and make any changes
> in this area.  I only want to have to do this once, never again!
> If you have any thoughts or strong preferences on the direction
> taken (particularly with the planned actions outlined below),
> please let me know sooner rather than later.
> 
> These are my thoughts/opinions/preferences:
> - I don't want to attempt to merge the two git trees, too much
> valuable revision history now exists, and the configure.in that
> is needed for each is very different (different tool chain)
> - I don't want a single install package (eg. named "pcp") as
> the "kmchart" package has lots of additional (GUI) dependencies.
> - Renaming kmchart/kmtime -> pmchart/pmtime is fine with me.  I
> will keep symlinks for backward compatibility, etc.
> - Need a new name for the "kmchart" package.  Suggestions have
> included: pcpgui, pcpvis, pcpviz, pcpmon, pcp-monitor.  At the
> moment I'm favouring the last two, probably the last one as it
> is the most clear.
> 
> These are my planned actions:
> - rename the kmchart git tree to pcp-monitor
> - rename the current pcp git tree to pcp-collector (removing any
> ambiguity, and making the packages consistent with some of the
> existing documentation)
> - split the current pcp rpm package into libraries, development
> packages and one pcp-collector package (pcp-3.0 timeframe, this
> has been requested by someone wishing to package us in Fedora).
> - rationalise libqmc and libpmc into one library as part of this
> transition (one library in the pcp-monitor package, not pcp),
> and rename kmdumptext to pmdumptext in the process.
> - Remove references to C++ compiler in pcp-collector configure
> process - all C++ code should end up in pcp-monitor hereafter.
> - rename libkmtime to libpmtime (this is a static-only lib atm,
> thankfully, but we should switch to making that shared as well).
> - update man pages, web pages, code, etc that refers to the km*
> names and instead use pm* names.
> - move pcpqa tree contents (back) into "qa" subdirectory in the
> pcp-collector git tree, so its clear what that is for.  kmchart
> (aka pcp-monitor) already has a "qa" subdirectory.

Not knowing what's in there, I ask naievely:  why not 'test' or 'tests'?

   - Kevin

> These things are likely to be done piece-by-piece and will take
> time.  I'm also trying to focus on the native Windows PCP port
> at the moment (so, even more time), but would like to use the
> right names for km{chart,time,etc} in the first version of that.
> 
> OK, any thoughts?  Suggestions?  Alternatives?  Personally, I
> think these are very positive changes, especially for new users
> by removing the wierd historical naming oddities that have crept
> into how we package things.

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