pcp
[Top] [All Lists]

Re: Simple fix needed, not docs? (was Re: [pcp] RFC2: fetchgroup api)

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: Simple fix needed, not docs? (was Re: [pcp] RFC2: fetchgroup api)
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Fri, 4 Dec 2015 13:14:26 -0500
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <447344479.34949675.1449195913043.JavaMail.zimbra@xxxxxxxxxx>
References: <20151201145903.GB31003@xxxxxxxxxx> <1224565686.32458903.1449038493129.JavaMail.zimbra@xxxxxxxxxx> <20151203001437.GA2531@xxxxxxxxxx> <37369073.33594680.1449118672756.JavaMail.zimbra@xxxxxxxxxx> <20151203141450.GB2531@xxxxxxxxxx> <447344479.34949675.1449195913043.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -


> Let me break it down.  This is another case of you refusing to work
> on fixing PCP bugs, instead only working on your pet features.  You
> open an absurd number of trivial bugzilla entries, which you then
> consider as Someone Elses Problem.  [...]

It seems a review of open source community philosophy is in order.  

You are a maintainer of PCP.  Your job is to build stuff, gratefully
accept contributions and bug reports, fix bugs, and cajole the
community into contributing more.

I am a user/contributor to PCP, not a maintainer.  My job is to
scratch my itches with quality contributions.  I'd like to think that
my itches happen to be good for PCP as a whole.  My job includes
reporting problems, and you're right, they sometimes feel numerous.
But in NO FOSS community is it EVER a requirement for a contributor to
fix those problems.

Note: there is no third category of "contributor-maintainer" - one who
has all the responsibilities of maintainership but none of the powers.
That would be absurd.


> > into a reoccurrance of the disgraceful PR1105 situation.
> 
> You were called out for actively ignoring a bug that prevented part of
> your feature from working [...]

This is a misrepresentation.  The feature that was completed in early
April worked fine.  It was useful, tested, documented, and met the
HACKING guidelines.  Its scope was slightly limited by the existence
of an ancient pcp bug, but that was in the opinion of its creator,
just fine for now.  See also "perfect is the enemy of the good".

One cannot seriously argue that such limitation should require a work
from being indefinitely held back.  By that reasoning, nothing could
be added incrementally or with known bugs/limitations.  No pmapi
function without python bindings.  No container code with naming
ambiguities.  No new client tool without a full range of pmda
extensions that could fill its every option/need.  It would be
ludicrous as a standard and indictable as a double-standard when
applied only to some.


- FChE

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