develooper Front page | perl.module-authors | Postings from November 2011

Re: The CPAN Covenant

Linda W
November 28, 2011 12:40
Re: The CPAN Covenant
Message ID:
David Cantrell wrote:

 >> ... Should be a problem for someone who ALWAYS has something more
 >> important to do than CPAN.
 > I wonder where that "always" came from.  Certainly not from me.

   Basic logic applied to your statements:

David Cantrell wrote:

 > On Thu, Nov 24, 2011 at 08:09:35AM -0800, Linda W wrote:
 >>if we want CPAN to be able to be relied upon.. it's can't have
 >> unaddressed bugs for months (let alone a  year or more)...
 > I promise to address bug reports quickly if you make them more important
 > than everything else in my life.

   The given reason for not fixing the bug, was that the fixing
of a particular module was less 'lower priority' than everything
in your life.

sets that include their definition.

   By definition, E⊇A (set >=), (A is any object, in set E).
It is usually the case that A⊃S (>), but minimally that A⊇S (>=).
   Thus E⊇S (>=).

If E is true "in life", then is is also true that "S" is also always true
in life.

    ∴ (therefore) -  the original statement!

(quod erat dēmōnstrandum (that which was to be demonstrated))

   It was an application of logic based on what you said.  It may not have
been what you *meant* --- that I can't know... my mind reads only extends
to the UK in the case of very close personal acquaintances.  Also
note, the proof was designed be 'amusing' (though dry), and in
no way mean to be offensive!)... ;-)

 > You also appear to have not noticed the word "quickly".  I will deal
 > with *all* bug reports eventually.

   Eh?  I DID mention months to a year -- to give an idea of 'quickly'.  But
eventually, doesn't cut it.   Companies can loose millions or billions of
dollars if something is stalled for a protracted period.

   If any SW developed for them by anyone, uses one of your modules
and it doesn't work, you've affected all those who have used your module.

   Having all of them look bad to their clients "until 'eventually'"
is a certain way to kill off contractors using perl to solve problems and
it's use.  Not acceptable....

   So often, coming to common terminology and agreement of 'definitions' is
90% of the work in reaching an agreement about something.
Damn language...screws us every time .. and worse when we move 1000's of
miles away from each other and isolate our selves for a few hundred years
and each evolve the 'common language' -- can the two diverse forks be
merged?   I will say it is better than grunts, but it's too cerebral for
human communication, as we are only half-rational (approx, maybe more or
less, depending on individual and who'd doing the evaluating).

   That's  one reason why people are so easily deceived/gullible:
It's constant driven into us that we should pay attention to what people
"say"...  and many (if not most) people do that by default.  The smart
ones are the ones that pay attention to all the cues...(dreadfully
limited in this form!)...


Oh...some text at the bottom of my post I forgot about... ;-)

 > Sometimes that will be by fixing
 > them, sometimes it will be by saying "no, that's not a bug".


   Very true, THOUGH 'bug' is a very vague term in SW.
(!)Some might limit it to 'program crash/hang/not work'.

   (2) Others would say (not consistent with spec (not really
applicable to CPAN modes usually) (3) its documentation (can
fix docs or code: pick one, but sometimes there is a preference...

   The one that the people in QA and specialized in Customer experience,
usability and satisfaction use the most stringent form, that I
feel should be what we strive for in excellence.  It has a few

   the 'worst' (maybe most unreasonable), is (A) 'something that
violates user expectations in behavior) (and note, 1 person,
isn't sufficient to generate a bug report...but when '10 people
call you an ass, you might consider buying a saddle', the saying goes.

   A.1) related: "Principle of "Least Surprise".

   A.2) related: "DWIM, or do the best you can (in the case of non
destructive operations); safety overrides convenience...

Hypothetical example:  A perl that continued after doing alot better job of
discerning user code errors, AND continued execution (w/a flag set).  Any
dangerous or file-changing ops would cause the program to halt
(Insufficient integrity to write to disk)... I.e. a program even with
warnings should have a -5 integrity, with errors, -30 up to -100, (these
are not unix 'nice values!)... starts with some base (base either solely on
the 'compile' OR perhaps on CPAN modules included and recent 'SMOKE tests',
number of tests vs.  # lines of source code...?  whatever...just ideas).

So maybe starts with a 50 integrity (**possibly** higher OR lower
depending on if running with privileges (or as root) (site policy;
not perl fiat).

Then could have levels of ops allowed (likely this would be in a module
of some sort)...though how much support from Base, (or Core), would be
unknown (0-??), but example rules might say 'same dir write: requires 25
or higher, subdir path, 35 or more, rest of FS 60 or more...
get picture.

   Not that I'm SUGGESTING the above be implemented, but showing it as an
EXAMPLE of providing a large amount of support for "DWIM" with gradations
of safety checks. Just getting basics fixed I encounter major resistance!
Any change to the status quo, serverely resisted... worse that
conservative GOP!...

   In the absence of such, more primitive heuristics need to be
used.  Stopping full 'initial compilation' based on 1 error, is very
primitive (though necessary in a primitive (as compared w/the language it
is parsing,  parser.

   Consistent and orthogonal interfaces.  If A & B are parallel
functions taking parallel argument types (maybe each as 1 different
arg type), the common args should be parsed the same...

   If A is based/derived from B (even documented as such), but
operates on a different type of object), functionality between the two
should have similar flexibility and semantics as appropriate to their
object.  The derived functions should be artificially restricted to not
allow similar params and similar behavior for its' class as the one it
followed upon.

 > sometimes it will be by saying "I'm not going to fix this, would you like
 > to take over maintenance?", and so on.


   Only sometimes?  ;-)   Hey, having a CVS/merc(hg)/git/... something setup
, where people can submit branches. .. would be an awesome (and probably is
really NEEDED in today's world), where you can allow commit access to
branches, or they can be submitted back to you for a final signoff (I would
want you to sign off -- I would want someone else's eyes to at least run my
code and made sure it ran and looked at it and optimally, glance over it to
see if there any *glaring* errors

I make mistakes ALL THE TIME -- the only way I was able to get things done
well in the past was by my ability to *make* mistakes and *correct them*
*faster* than most people.   Now days, with my typing impeded, and
programming time physically limited, .. work is alot slower to the point of
near nothingness.  And it's NOT possible to say "oh, if you go more slowly
and do designs and flow charts and...all the other things that make
managers feel warm and fuzzy, then you will get things right the first time
.. I have yet to meet someone who is able to consistently do it right the
first time.

   As I rarely feel something is good enough to be handed off to anyone or
used by anyone else...(I think my having such high standards for myself
that prevent me from releasing set the stage for it being especially
galling when I see unfinished modules on CPAN, that are 5-7 years old where
the author setup a project, and, in some cases did no work (others, a
framework, but nothing useable.  a 0.1 release).

Such unfinished projects should be removed from main listings after, at
most a year...(when detected.)... Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About