nathans wrote:
> [...] 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 [...]
I'm unconvinced that cleaving the project this way is helpful, and
wonder what other members of the community think.
> ----- 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.
Yet this proposed alternative scheme puts them into the same
e.g. fedora distribution packages. It does not solve any hypothetical
licensing concerns, or team workload, or bug triage procedures, or
indeed who fixes what bugs.
>> 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.
And yet the proposal is to move pmwebd core code out too - a baby &
bathwater overreaction. From a technical point of view, pmwebd fits
fine where it is, including the build system, documentation qa, and
does not require any of the jsdemos/ stuff to be useful.
> 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
Agreed, and ISTM that this undermines the argument that all this code
must be separated from pcp.git *because* some of it is verbatim
upstream code, and we may not be able to maintain it. New web app
code we write is exactly stuff we'd maintain.
> [...] 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. [...]
Please substantiate this concern. It is difficult to see how the
power of arbitrary shell scripts (qa/NNN) is not sufficient to wrap
whatever mechanical webapp-testing widget might eventually be used.
> 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. [...]
I don't see the connection. Ken rightly points out that the
build/test trees must be flexible as to prerequisites and older
platforms. But they can/should be identically flexible, whether
or not they are stored in the same git repository.
> 2. Already, the web package is approx double the size of core PCP
> (2.9M vs 1.5M) [...] It contains 300+ more files than the core PCP
> package [...]
Is there a maximum limit for a core-pcp source distribution in bytes
and file count? What resources are at risk of exhaustion by an extra
few megabytes of sources or optional binaries?
- FChE
|