> Modules with reliable owners, such as Soap::Lite, deserve the highest
> level of confidence.
Currently SOAP::Lite doesn't have an 'owner' per se. I sent a patch
into rt.cpan.org a few weeks ago, and as a result I was given COMAINT
on CPAN for it, applied many fixes, and released 0.716 (which contains
at least one regression) a couple weeks ago. Now I'm working on 0.717,
and hopefully someone else will take this module on in a year.
So there are maintainers - when one becomes occupied with real world
tasks such as job, family, etc, then bugs get filed, and others step
up. It's generally how CPAN (and now Github) works to a large degree.
On Fri, May 31, 2013 at 1:41 PM, Jim Schueler <jschue...@eloquency.com> wrote:
>> With regards to Apache::DBI, it is very much supported :)
>
>
> No. It is not. What little I know of you, you seem knowledgable and
> experienced. But you don't seem to have read this thread. The
> documentation says that the module will be supported by this list, and the
> facts now demonstrate otherwise.
>
> Several contributors have responded now. To paraphrase, they will (and I
> will and so will others) help the best they can. But that's not what the
> documentation says. I guess I'm just one of those whiners who expects the
> documentation to be reliable.
>
> I followed this thread from the beginning. I compared the original
> observations with the documentation. And either the documentation is wrong
> or (more likely) incomplete. I think it's reasonable to assume that if no
> one steps up to take ownership, there is no owner. And hence the code is
> unsupported.
>
> Early on, I tried to clarify. Which I'll repeat:
>
> If the code has no significant user base and no identifiable
> owner/maintainer, use at your own risk. Pretty much what you say
> below.
>
> If the code has a significant user base but no identifiable owner,
> there's a lot less risk because you can get support from other users.
>
> Modules with reliable owners, such as Soap::Lite, deserve the highest
> level of confidence.
>
> Apache::DBI has no owner and therefore falls in category #2. Or maybe
> someone will step foward, and thus category #3. Otherwise, your comments
> below say the same thing. Yet for some reason, you turned the big platitude
> guns on me.
>
> By omission, there seems to be consensus on these guidelines. All the
> quibbling revolves around my estimate that most modules fall in the first
> category. Personally, I would prefer no one estimated that 97.5% (or
> 118,000 perl modules) are still actively supported by their authors/
> designated successors. Because I think that claim strains credibility.
>
>> ...this comes with the general open source software caveat - "Using open
>>
>> source software doesn't mean someone will do *your work* for free".
>
>
> I didn't originate the thread, but this response offends me. If someone
> observes a problem with a module, is the point to discredit them instead?
>
> So far, there seems to be a tendency to overlook the substance of the
> discussion and react defensively to outsiders (as though I haven't
> participated here for 14 or 15 years). What's up with that?
>
> Thanks for letting me get that off my chest.
>
> -Jim
>
>
>
>
> On Fri, 31 May 2013, Fred Moyer wrote:
>
>>> In their absence, I'd note that your post has an interesting ambiguity:
>>> Is
>>> the number of unsupported modules 2.5% or 25%?
>>
>>
>> The 'supported' metric doesn't really translate the same in reference
>> to open source software as it does to commercial software. When a
>> commercial software product becomes unsupported (think IE6), then you
>> are out in the cold. You don't have the source code, so you can't fix
>> an issue with it, or hire someone to fix the issue. Unless you are
>> really good with a hex code editor and patching binary files, you're
>> out of luck.
>>
>> With open source software like Perl, you may see statements like 'Perl
>> 5.6 is no longer officially supported'. This means you probably won't
>> be able to get the P5P team to fix bugs or security issues if they
>> come up. Still, you have the source code, so you can fix it yourself.
>>
>> CPAN is a bit more murky in that individual authors can decide to
>> deprecate modules, or they can drop off the face of the earth, but
>> widely used modules such as Apache::DBI, SOAP::Lite (maintenance
>> recently stewarded by yours truly) will almost always have volunteers
>> step up and maintain them, because those volunteers need those modules
>> to be functioning for own work. In terms of a supported metric, I'd
>> say modules that are used by more than a few people are supported
>> 100%.
>>
>> With regards to Apache::DBI, it is very much supported :) But this
>> comes with the general open source software caveat - "Using open
>> source software doesn't mean someone will do *your work* for free". If
>> there's a feature that appeals to more than a couple users, or a bug
>> that affects more than a couple users, odds are that it will get
>> fixed. Features that only one user is after will likely not be
>> implemented by the maintainers, but patches for those features are
>> usually readily accepted.
>>
>> On Fri, May 31, 2013 at 10:30 AM, Jim Schueler <jschue...@eloquency.com>
>> wrote:
>>>
>>> No apology please. In terms of trying to qualify any of this, a larger
>>> statistical pool is better. And I am no authority. My perceptions are
>>> largely based on forum postings which causes an inherent bias.
>>>
>>> I'd love to see this conversation continue, especially if participants
>>> included those who commit significant resources to their technology
>>> decisions. In other words, people who hire and pay Perl programmers.
>>> They're likely to be as skeptical as I am. I've never been a
>>> cheerleader.
>>>
>>> In their absence, I'd note that your post has an interesting ambiguity:
>>> Is
>>> the number of unsupported modules 2.5% or 25%? (For more rhetorical
>>> nit-picking, you probably don't use the ones that don't work :) Also,
>>> the
>>> significant question seems to be whether Apache::DBI is supported or not.
>>> From Mr. Zheng's point-of-view (in this case, the one that matters) the
>>> number might be much higher.
>>>
>>> -Jim
>>>
>>>
>>> On Fri, 31 May 2013, André Warnier wrote:
>>>
>>>> Just butting in, apologies.
>>>>
>>>> It may not have been Jim's intention below, but I get the impression
>>>> that
>>>> his comments on CPAN are a bit harsh.
>>>>
>>>> It is true that a number of modules are apparently no longer supported.
>>>> I
>>>> have used many modules over the years, and sometimes have had problems
>>>> with
>>>> some of them (mostly not though). And when for these problematic cases,
>>>> I
>>>> have tried to get help, the results have beem mixed; but the mix for me
>>>> has
>>>> been rather good. I would say that in my case, 90% of the CPAN modules I
>>>> ever used worked out of the box. For the 10% remaining, in 75% of the
>>>> cases
>>>> I did get help from the person advertised as the author or the
>>>> maintainer,
>>>> and in 25% of cases I never got a response.
>>>> But then, as Jim himself indicated, people move on, without necessarily
>>>> changing their email addresses. Considering how old some of these
>>>> modules
>>>> are, I guess people also retire, or even pass away.
>>>>
>>>> But the fact of the matter is that CPAN is still an incredible resource,
>>>> unequalled in my view by any other similar module library of any other
>>>> language anywhere. And I find it amazing that at least 90% of the
>>>> modules
>>>> which I have downloaded from CPAN and used over the last 15 years, just
>>>> work, and moreover keep on working through many, many iterations of
>>>> programs
>>>> and perl versions, and that in fact one very rarely needs additional
>>>> support
>>>> for them. When I compare this with other programming languages and
>>>> support
>>>> libraries, I believe we perl programmers are incredibly spoiled.
>>>>
>>>> Another area where CPAN shines, is the documentation of most modules. I
>>>> cannot count the times where I was faced with a request in an area of
>>>> which
>>>> I knew nothing at all, and have just browsed CPAN for modules related to
>>>> that area, just to read their documentation and get at least an idea of
>>>> what
>>>> this was all about.
>>>> In recent years, Wikipedia may slowly becoming a runner-up, in terms of
>>>> general information. But when it comes down to the nitty-gritty of
>>>> interfacing with whatever API (or lack of ditto) programmers in their
>>>> most
>>>> delirious moments might have come up with, these CPAN modules are
>>>> unbeatable. Even if after that you decide to program your stuff in
>>>> another
>>>> language than perl, it's still useful.
>>>> (Just for fun, go into CPAN and search for "NATO" (or more
>>>> pragmatically,
>>>> for "sharepoint" e.g.)(or even, God forbid, for "Google" or "Facebook"
>>>> ;-));
>>>> who thinks of such things ?)
>>>>
>>>> So, to summarise : that some modules on CPAN would be marked as
>>>> "maintained" or "supported" and would turn out on closer inspection not
>>>> to
>>>> really be anymore, I find this a very small price to pay for the wealth
>>>> of
>>>> good information and working code that lives there.
>>>>
>>>> My sincerest thanks to CPAN and all its contributors and maintainers
>>>> over
>>>> the years (that includes you of course, Jim). What you have done and
>>>> are
>>>> doing is of incredible benefit to many, many programmers worldwide.
>>>>
>>>> André
>>>>
>>>>
>>>> Jim Schueler wrote:
>>>>>
>>>>>
>>>>> I still use Alpine. And they never fixed the bug where ctrl-c (to
>>>>> cancel
>>>>> a message) and ctrl-x (to send) are so easily confused. Oops. Maybe
>>>>> it's
>>>>> time to start using a mouse.
>>>>>
>>>>> Having wasted so much time, I'll try to be succinct:
>>>>>
>>>>> Most modules on CPAN are bascially throwaways and not supported at
>>>>> all.
>>>>> Use them at your own risk.
>>>>>
>>>>> There are some modules that are just obsolete. Good intentions
>>>>> aside,
>>>>> the developers lost interest and moved on. These are less risky if
>>>>> there's an established user base.
>>>>>
>>>>> There are some very good modules, widely used, that are fully
>>>>> supported
>>>>> and perfectly safe for a production environment.
>>>>>
>>>>> Most mod_perl modules, especially the core modules, fall into that
>>>>> last,
>>>>> gold standard, category. In many cases, support is transferred from
>>>>> one
>>>>> individual to another. And so that commitment is documented. But if a
>>>>> module is no longer supported, don't lie about it. Support forums are
>>>>> an
>>>>> incredible resource. But if commercial software developers similarly
>>>>> blurred this distinction, every p.o.s. would be advertising free 24x7
>>>>> tech
>>>>> support.
>>>>>
>>>>> Apache::DBI seems like a #2 pretending to be a #3. On the basis of
>>>>> your
>>>>> response, I've concluded that Apache::DBI is no longer supported and
>>>>> has
>>>>> been superceded by newer modules. Especially if no one responds and
>>>>> explicitly accepts the responsibility, this seems like the most
>>>>> appropriate
>>>>> answer for the poster of the original thread.
>>>>>
>>>>> I owe you a :) from a couple posts ago. :)
>>>>>
>>>>> -Jim
>>>>>
>>>>> On Fri, 31 May 2013, Perrin Harkins wrote:
>>>>>
>>>>>> Hi Jim,
>>>>>> I appreciate the thought, but I'm not the mod_perl list. If you look
>>>>>> at
>>>>>> who
>>>>>> has done the most support around here recently, it's probably Torsten.
>>>>>> (Thanks Torsten!) More to the point, there are many people on the
>>>>>> list
>>>>>> who
>>>>>> know enough perl to help with a question about Apache::DBI. It's a
>>>>>> common
>>>>>> practice to point people here for support on mod_perl modules.
>>>>>>
>>>>>> What are you getting at? Is there a module that you're having trouble
>>>>>> with
>>>>>> and can't get support for?
>>>>>>
>>>>>> - Perrin
>>>>>>
>>>>>>
>>>>>> On Fri, May 31, 2013 at 10:56 AM, Jim Schueler
>>>>>> <jschue...@eloquency.com>
>>>>>> wrote:
>>>>>> There's an existing thread with an Apache::DBI question. But
>>>>>> since I want to post a separate question to this list, I decided
>>>>>> to start a new thread.
>>>>>>
>>>>>> Just got done reading the Man page for Apache::DBI. One of the
>>>>>> last notes suggests that this package is obsolete (having been
>>>>>> replaced by Class::DBI or DBIx::CLASS). Beyond that is the
>>>>>> following:
>>>>>>
>>>>>> Edmund Mergl was the original author of Apache::DBI. It is now
>>>>>> supported
>>>>>> and maintained by the modperl mailinglist, see the mod_perl
>>>>>> documentation
>>>>>> for instructions on how to subscribe.
>>>>>>
>>>>>> Unless Perrin Harkins agreed to take over support for this
>>>>>> module, then that statement is not true. Otherwise, out of
>>>>>> respect for Perrin, I'll try to be general.
>>>>>>
>>>>>> (Aside: Am I the only developer that comes across 'unless () {}
>>>>>> else {}' constructions?)
>>>>>>
>>>>>> It seems very few distros on CPAN are actually supported. For
>>>>>> my part, I still monitor this list to support my own
>>>>>> contributions from *many* years ago. And I k
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>
