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