Apache::DBI

[Jim Schueler <js...@eloquency.com>]

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

Re: [OT] Apache::DBI

[André Warnier <aw...@ice-sa.com>]

Jim Schueler 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%? 

Note that this was prefixed by "for the 10% remaining,", so it was indeed 2.5%.
My mothertongue is not English, so I am subject to the occasional linguistic slippage.
It would probably have been clearer had I written "Of the remaining 10%,".

  (For more rhetorical
> nit-picking, you probably don't use the ones that don't work :)

Maybe. But I do use quite a few that do work and never needed any support.
And there are thousands of add-on modules in other languages that don't work and that I 
don't use either.  (So where does that leave us, statistically speaking ?)

I believe that Vincent's comment is right on the spot : perl, and perl CPAN modules, and 
mod_perl, generally work so well that there are not a lot of support requests, and that 
situation by itself makes them rather "transparent". "Happy people have no History" 
(French proverb, translated literally).

There is a similar situation elsewhere in the IT world : some environments or applications 
need a lot of support just to keep running.  Therefore, they need a large support staff. 
Therefore, their department grows larger and their boss gets a lot of clout and a big 
budget.  In contrast, the application which just works and doesn't require much support, 
does not make headlines, tends to get forgotten and gets less staff, a smaller boss and a 
smaller budget.  Unfair but often seen.

Maybe the perl situation is not so bad in reality though.  I have it from some usually 
reliable sources that there is a gradual regain of popularity of perl among younger 
programmers.  That is certainly the case among the young programmers that I employ.  They 
usually arrive all infatuated by things java and PHP and .net and sharp, and look 
sceptically at best upon anything around perl.  Then they are asked to solve some simple 
issues, and pick their preferred language to do it.  Then they are shown the perl way of 
doing it, and that generally succeeds in getting their attention.
It's a slow process, but one has to patiently overcome years of Java and MS propaganda, 
and that doesn't happen in a day.


   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 
>>>> <js...@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
>>>>
>>>>
>>>>
>>>>
>>

Re: [OT] Apache::DBI

[Perrin Harkins <ph...@gmail.com>]

Jim,

I just don't see the issue with not having an individual's name on one of
the mod_perl modules as the support contact.  To me, Apache::DBI is being
supported, exactly as the documentation says.  Someone wrote to the mailing
list, asked a question, and received responses that were trying to be
helpful.  Knowledgeable people offering "to help the best they can" is the
only kind of support I expect to see on an open source project.  In this
case you get that from a whole group, not just one person.

If I need help with DBI, I might write to dbi-users, but I don't expect a
personal response from Tim Bunce every time I ask a question.  Of course,
if I wrote in with a major bug or security issue (or offered chocolate), I
probably would get a response from Tim, just like similar messages to this
list about mod_perl have been responded to by the mod_perl PMC.

Is the issue for you that the original author listed on the module is no
longer on the list?  There are many of us here, including me, who have
worked with, debugged, patched, and partially rewritten Apache::DBI.  We
own it.

- Perrin



On Fri, May 31, 2013 at 4:41 PM, Jim Schueler <js...@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 <js...@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 <
>>>>>> jschueler@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>

Re: [OT] Apache::DBI

[André Warnier <aw...@ice-sa.com>]

Jim,

Jim Schueler 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.

I employ and pay perl programmers.  I even initially give a job to young people who are 
not perl programmers and initially consider perl as something slightly disreputable - 
because that's what they generally learn in school - and make the effort to "convert" them 
to perl.

I also have the greatest respect and appreciation for people who create interesting perl 
modules, and who then go the extra mile to make these modules available to others on CPAN. 
  And I will admit to being in that respect merely a "user", and to never have gone that 
same extra mile with modules which my employees or myself developed in-house.

When I consequently find and use a CPAN module, and occasionally find a problem with it, 
and occasionally find out that despite what the documentation says, it appears that it is 
unsupported, I do not however jump through the roof, as you seem to be doing in this case.

You are right, it is not entirely correct that the documentation of a CPAN module would 
state that it is supported, when in reality it may turn out that it is not so.

But what is to do about it, really ?
Say that in 5 years, someone downloads Google::Oauth, has a problem with it, looks at the 
"See Also" and the "Author", tries to contact this guy, and finds out that nobody 
responds.  What should happen then ?  There are a million possible reasons why the person 
who maybe usually responds to such enquiries on this list, may be temporarily or 
definitely unavailable these days.  Should someone hire a booty hunter to track him down 
and force him to answer, or to rectify the documentation or else ?
Nobody is really being paid to spend time scanning the CPAN module documentation, to find 
out if there is really someone supporting that module, and updating the documentation to 
say "unsupported, use at your own risk".

Can you think of a practical solution to that, for 118,000 modules and counting ?

> 
> 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 use CPAN all the time, I have done so for many years, and I never paid a cent for it.  I 
download modules, and I incorporate them into applications which I sell for a living.  I 
have occasionally sent my thanks to a CPAN module developer, but I have never paid them a 
commission when I sold their module as part of my applications.
On the other hand, I also do not /expect/ to get something for nothing.
So when I find out that some module is unsupported, while the documentation says that it 
is, I accept that.  I then try to get help somewhere else, or figure out by myself if I 
can understand the source and correct the problem myself.  If I can, I will generally try 
to send some email to the person mentioned as the author or the maintainer anyway.  Most 
of the times when I have done that, I haven't got an acknowledgement either.  Again, I 
accept that, since I didn't pay for the thing in the first place.
Are your expectations different ?

> 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.

Agreed.

> 
> 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.

Agreed.

> 
>   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.
>

Agreed.

>   Modules with reliable owners, such as Soap::Lite, deserve the highest
>   level of confidence.
>

Agreed.

> 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.
>

If by this you refer to my previous relation of my own experience, I wasn't trying to 
express some general statistic, and i never claimed that 97.5% of modules are actively 
supported.
The only things which I stated was that in my own limited experience,
- 90% of the modules which I ever downloaded and used worked as I expected and /did not 
need any support/ (for me).  In that case, whether they are actually "actively supported" 
or not is effectively irrelevant, and I never even tried to check if they were supported.
- of the remainder 10% (which did not work as expected and for which I seeked support), 
3/4 of them seemed to be effectively supported, since I did get help.  Whether that was 
help from the person mentioned as the author or maintainer or not, I honestly couldn't 
tell anymore; but I did get help in resolving my problem, and to me this counts as 
"supported".  In the last few months, I remember that we needed help once, for the 
SOAP::WSDL module, and we did get immediate and effective help from the author. But of 
course this is purely anecdotical and not a base for real statistics.
- and only 1/4 (thus 2.5% of the total number of modules that we tried to use) seemed to 
be indeed unsupported, and either we fixed the issue ourselves or switched to an 
alternative module on CPAN - for which in our case there always seemed to be one when we 
really needed it.

That does not contradict your classification above.  But it presents the same data in 
another way, from the perspective of a potential user of CPAN modules.
Instead of classifying most modules as "unsupported, use at your own risks" - which sounds 
rather sceptical if not bad - I would say "90% of CPAN modules work just fine as 
downloaded, don't worry" which sounds a lot better and in my view also reflects the 
practical reality better (mine, anyway).

>> ...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?
>

No, but did anyone really try to do that ?
When I re-read the posts in this thread, I do not really see that.

It seems to me instead that you were the one to turn on the big guns of dismal 
disappointment, when maybe there wasn't a real reason to react that way.

You took the case of one issue with one CPAN module, and seemed to turn it into a general 
comment about all CPAN modules, and you seem to imply that most CPAN modules are 
unsupported - although the documentation says otherwise - and that this automatically 
translates to a general quality issue of these CPAN modules. I believe that this apparent 
generalisation was what some people here mostly reacted to.

> 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.
>

Welcome :).


>  -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 
>> <js...@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 
>>>>>> <js...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>

Re: [OT] Apache::DBI

[Fred Moyer <fr...@redhotpenguin.com>]

> 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 <js...@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 <js...@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
>>>>>> <js...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>

Re: [OT] Apache::DBI

[Jim Schueler <js...@eloquency.com>]

> 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 <js...@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 <js...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>
>

Re: [OT] Apache::DBI

[Fred Moyer <fr...@redhotpenguin.com>]

> 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 <js...@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 <js...@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
>>>>
>>>>
>>>>
>>>>
>

Re: [OT] Apache::DBI

[Jim Schueler <js...@eloquency.com>]

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 <js...@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
>>> 
>>> 
>>> 
>>> 
>

Re: [OT] Apache::DBI

[André Warnier <aw...@ice-sa.com>]

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 <js...@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
>>
>>
>>
>>

Re: Apache::DBI

[Vincent Veyron <vv...@wanadoo.fr>]

>  the perl web dev world is more splintered and there are fewer people
> on the mod_perl list than there used to be.  That's a little sad for
> me to see, but the new stuff is pretty nice too, and lots of people
> are still using mod_perl and answering questions on this list.
> 

I wonder if the fact that mod_perl works so well sometimes plays against
it?

Jim's comments remind me of a few others before on the list, with the
author asking if it's dead because they don't see any activity. It's not
dead at all, it just does the job, quietly and very well. 

There was a discussion a while back on HN or /., started by someone
complaining that some linux packages hadn't changed in years (can't
remember exactly now, but it was about essential things like ls, ps...
commands being used everyday by millions). The reason being of course
that these packages were just fine as they were.

-- 
Salutations, Vincent Veyron
http://marica.fr/site/demonstration
Logiciel de gestion des contentieux juridiques et des sinistres d'assurance

Re: Apache::DBI

[Perrin Harkins <ph...@gmail.com>]

The mailing list has been the official place for support of all bundled
mod_perl modules for as long as I can remember.  I don't think there's a
rule about perl core modules being passed between individuals either,
although I could be wrong.  Sending people to a mailing list for support is
a common practice with any widely used module, e.g. DBI.

Apache::DBI is obsolete in the sense that most people are using an ORM
framework that handles database persistence for them, so they have no use
for Apache::DBI.  It's not broken, and people should feel free to use it if
it fits their use case.  It has certain advantages over
DBI->connect_cached() which have been discussed here many times.

I'm not sure why you're concluding that Apache::DBI is unsupported.  To me,
getting multiple responses on a mailing list is pretty much Platinum Level
Support for open source.  If no one stepping forward to say "I own X, let
me debug it for you" means that X is unsupported and obsolete, then I think
we're all in trouble.

Open source support has always been laissez-faire (unless you choose to
hire someone for it).  The only thing that has changed recently is that
with more viable web runtime options to choose from (PSGI, FastCGI's
comeback, etc.), the perl web dev world is more splintered and there are
fewer people on the mod_perl list than there used to be.  That's a little
sad for me to see, but the new stuff is pretty nice too, and lots of people
are still using mod_perl and answering questions on this list.

- Perrin


On Fri, May 31, 2013 at 11:50 AM, Jim Schueler <js...@eloquency.com>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 <js...@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
>>
>>
>>
>>

Re: Apache::DBI

[Jim Schueler <js...@eloquency.com>]

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 <js...@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
> 
> 
> 
>

Re: Apache::DBI

[Perrin Harkins <ph...@gmail.com>]

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 <js...@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
>