Hi guys,
Sorry its taken so long for me to return to this, I'm finding it to
be quite a complex topic to grapple with.
TL;DR ...
I'm convinced that now is a good time to change the way we manage PCP
sources, while it's still early days in the PCP web & middleware areas
- a working prototype model to move us all forward is presented here.
----- Original Message -----
> > [...]
> > As discussed elsewhere before your vacation, I'm not comfortable
> > adding copies of 100s of 1000s of lines of javascript code and
> > images to core PCP from projects that we didn't author, nor have
> > plans/skills to maintain ourselves.
>
> I'm not comfortable either, but solutions that make everyone
> comfortable are not likely to exist soon.
Agreed. I'm semi-comfortable with this being released separately to
core PCP, and not at all comfortable with any of it embedded in the
PCP git tree.
> Would your discomfort be eased if this same non-embedding embedding
> were experimented with for purposes of the web applications? Namely,
> include src tarballs of graphite/grafana/etc. within pcp src.rpm's,
> and have these be untarred under /usr/share/pcp/jsdemos during the
> build/install phase?
That's an improvement of sorts, but still only a stop-gap measure. What
does the web future for PCP look like? Are we only going to have static
javascript code only (below jsdemos or hidden elsewhere) forever, and not
ever need to write any code ourselves?
I think that's unlikely, and I expect the time will soon come when we have
to embrace writing and testing custom javascript code too (which means yet
more tools and dependencies in our toolchain). The core PCP tree would be
a poor place to be doing this IMO - with its current build system, testing
model not ideal for web/javascript code, and so on.
How would y'all feel about moving these sources outside of the core PCP
tree, into a new tree with build/test/deploy models more suited toward
the new code? (CMake? like Paul Colby has been doing with his new C++
code, and similarly described here by some Netflix folks for their C++ &
javascript needs - http://www.kitware.com/source/home/post/127 ?).
I would be happy to help out with contributing to such a tree, but primary
maintainer role really needs to sit with someone who a/ wrote the code and
b/ has the passion to drive those components forward, and building the web
community around it.
Below is a working build which prototypes this re-arrangement and includes
some first-thoughts on how to pull Java code into the extended PCP family
in the same way (I'm planning to take that project on soon - it shares the
same build/release issues, so worth our consideration here).
git://git.pcp.io/nathans/pcp.git
git://git.pcp.io/nathans/pcp-web-manager.git
git://git.pcp.io/nathans/pcp-jvm-metrics.git
In particular, the build/rpm/fedora.spec shows how these trees share that
single unifying RPM build mechanism, but can be maintained / released via
separate build systems (autoconf+make/cmake+make/maven/whatever). It uses
%sources for the RPM side of things as we've discussed - it's surprisingly
simple in the end. There's more work to do there depending on the outcome
of the CMake side-discussion. But its effectively working so please check
it out and see if this is something you'd be comfortable with.
Finally, two more considerations:
1. The class of problem that Ken raised here ...
http://www.pcp.io/pipermail/pcp/2014-September/005440.html
is going to become far worse for javascript and java builds. pcp-gui was
a mature well-understood tree, and we knew exactly how to merge it in - yet
still caused massive headaches and fallout. I know these new areas present
many more challenges and we do not need to go through that all over again
(esp. for Ken who does more core PCP QA heavy lifting than anyone, by far).
2. Already, the web package is approx double the size of core PCP (2.9M vs
1.5M) - gives an indication to the scale of web stuff, already, that we're
talking about here. It contains 300+ more files than the core PCP package
too (>1200 files installed). Those JVM trees I'll be starting with aren't
of insignificant size & complexity either.
Thoughts? Frank, would you be happy to take on the pcp-web-manager tree,
to love and cherish as best you see fit? I'll be moving pcp-jvm-metrics
forward soon and beginning the Parfait-meets-Metrics work there (if anyone
with JVM expertise wants to help me out with that new tree, let me know!)
Thanks all, and have a most excellent weekend.
cheers.
--
Nathan
|