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.
