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

Re: The CPAN Covenant

From:
David Cantrell
Date:
November 29, 2011 05:09
Subject:
Re: The CPAN Covenant
Message ID:
20111129130934.GE14198@bytemark.barnyard.co.uk
On Mon, Nov 28, 2011 at 10:07:59AM -0800, Linda W wrote:

> The  person who I responded clearly stated that unless I was willing to
> pay to make it his highest priority, then my patches would be given lowest
> priority.

No I didn't.

I merely pointed out how you could, if it were important enough to you,
get something to the front of my queue.  Perhaps you're a Lisp
programmer, and so were thinking of car (the head of a list, ie the
thing that's at the front of the queue) and cdr (the rest of the list).
But note that the rest of the list is an *ordered list* that itself has
a car and a cdr.

The opposite of "move something to the front of the queue" is not "move
it to the back of the queue", it's "do not move it to the front of the
queue".

>            Personally, I don't like that attitude nor do I believe it
> belongs on CPAN which is supposed to be about you **giving** to the
> community (not charging them for it!)

What part of you being able to download my stuff and use it for free
doesn't count as me giving to the community?

>   If a developer can only support or is only willing to support some subset
> of patches, then then their name space has to be subdivided by architecture

Errm?  I'm not willing to accept patches to Number::Phone (to take just
one example) which change the interface, unless the interface itself can
be shown to be buggy.  How do you propose that we then split it by
architecture to reflect this?

I'm also not willing to accept architecture-specific patches unless they
fix a bug.  I won't accept them even if they make things a squillion
times faster, because they make maintenance and testing harder.

>   Which is the right idea, but Bad for perl/cpan, since the first thing
> people will find in current searches is the higher level module.  I also do
> not want to see 'Maintained or not maintained' on CPAN.  as unmaintained
> modules (that have outstanding bugs/problems), have no place on CPAN.

Just because something has outstanding bugs doesn't mean it isn't
useful.  One of my modules has problems on FreeBSD and Windows, but
works everywhere else.  Or at least everywhere else that the
CPAN-testers have tried it.

I know what the bug is, I've known since very shortly after I got the
first test failure report six months ago.  It's a small bug, easy to
fix, but I've not had the time to fix it.  I could have *made* the time,
but it's a really boring bug to fix and so it has never gone to the
front of the queue.

For the avoidance of doubt by those whose first language is Lisp, that
does *not* mean that it's at the *back* of the queue :-)

Just for a giggle, here's the bug queues for the most important modules
on the CPAN:
  https://rt.cpan.org/Public/Dist/Display.html?Name=CPAN
  https://rt.cpan.org/Public/Dist/Display.html?Name=DBI
  https://rt.cpan.org/Public/Dist/Display.html?Name=Test-Simple
  https://rt.cpan.org/Public/Dist/Display.html?Name=DateTime

some of those reports are *years* old, which just goes to show that
there being open bug reports isn't a useful metric, even if there's been
no recent release.

> Red Herring, since I wouldn't suggest (especially at this point that such
> decisions be enforced and put into place without the interaction and
> concensus of 'some group' of current CPAN-lib/site maintainers, or some
> *plurality*, of some equivalent mailing list.  People who are
> 'obstructionists' on mailing lists will be ignored.  If they can't come up
> with concrete, engineering based decisions to block something, vague whine
> about 'well I dunno, i think this should be thought about for a years,,, it
> might cause problems in <insert corner case>...   Simple majority stuff is
> 'bad', (whether it's > or < 50%).

Talking of vague obstructionist whiners, you have yet to come up with
concrete proposals of how to implement all of those changes you've
talked about.  Your proposal needs to address how it can be achieved
using volunteer labour and resources, how it won't drive contributors
away, or if it does drive them away why that is a good thing.  Use
both sides of the paper.  You may begin now.

> > who contributed their work to the CPAN for the public interest, free of
> > charge.
>   And the guys standing on the free way exits often will start cleaning
> your window "for free in the public interest as well"...  so?  Did I ask
> them to?

Bad analogy.  Those dumb bastards who clean my car without me asking
them to are doing something to me for free.  People who upload stuff to
the CPAN are *not* doing anything to me for free.  They are merely
making a free service available that I can choose to use if I wish.
A better analogy would be with someone advertising free carwashes, and
maybe offering an improved service for a fee.  That improved service
might be letting you jump to the front of the queue, past all the
free-loaders.

>           Doing things out of right intentions only means your a good
> person -- but it doesn't mean your are actually doing what is best for the
> community or fulfilling the need(s) of the community.

Volunteers can never be expected to do what is best for the community.
Optimising is HARD.

This is one of the reasons that charities have employees as well as
volunteers.  Many of those employees' jobs boil down to optimisation -
getting the best that you can out of the volunteers without driving
them away.  This is definitely not done by telling the volunteers that
"Thou Shalt Do It My Way".

Hmm, I just had a thought about what would make a great talk for a YAPC
or a Perl Workshop ...

-- 
David Cantrell | Nth greatest programmer in the world

There is no one true indentation style,
But if there were K&R would be Its Prophets.
Peace be upon Their Holy Beards.



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About