http://www.perlmonks.org?node_id=1065353

boftx has asked for the wisdom of the Perl Monks concerning the following question:

I've just gotten bit by this bug in AppConfig. The observant person will note that it is over 5 years old.

My question is this, do I work around it, possibly supplying a sub-class that applies the patch mentioned in the bug report, or just make a note of it in my own docs and go on? Beyond that, there are numerous bug reports for that module, seems a bit dis-concerting for something that is included as part of CORE.

I decided to use AppConfig in the first place because it was part of the CORE distro and had support for Getopt::Long as well as a config file. In fairness, the POD for AppConfig mentions that Getopt::Long support is "experimental".

Update: Double-checked and AppConfig is NOT part of CORE as pointed out below.

It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
  • Comment on Best way to deal with a bug in a CORE Module

Replies are listed 'Best First'.
Re: Best way to deal with a bug in a CORE Module (release patched version)
by Anonymous Monk on Dec 03, 2013 at 02:48 UTC

    just make a note of it in my own docs and go on?

    Bump the version number and make a note in your code/Makefile.PL

    If you have a CPAN account, you should release a patched version and save the next monk-ey from having to go to rt, find patch, download patch, apply patch, deploy patch ... they can just  cpan BOTFX/AppConfig-1.6601.tar.gz and be done with it

    Beyond that, there are numerous bug reports for that module, seems a bit dis-concerting for something that is included as part of CORE... CORE...

    Where do you get that idea?

    $ corelist AppConfig Data for 2013-11-20 AppConfig was not in CORE (or so I think)

      I could be mistaken, I thought I saw it in the CORE list. But then again, jokes about "old-timers disease" aren't so funny anymore. I just checked on the Perl site http://perldoc.perl.org/index-modules-A.html so it would appear you are correct.

      It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
Re: Best way to deal with a bug in a CORE Module
by pemungkah (Priest) on Dec 03, 2013 at 02:34 UTC
    It depends on how badly you need it. If you can patch it yourself, do that and submit the patch to the author. I'm assuming you have some build or install mechanism you use that installs known versions of your CPAN modules; just make your fixed version the one that gets installed. If you can get along without it, note in your docs that you didn't use it because it's buggy, so the next person along doesn't try to use it. (Mentioning the link to the open bug would be a nice thing to do, in case the bug gets closed.)

    Fixing the bug(s) and sending a pull request to the author would be a mitzvah (and a nice way to get into the committers list).

      If you decide to apply a patch locally, I recommend using CPAN.pm's distroprefs to apply it. Unless, of course, you're being sensible and convert your dependencies into rpm/deb/whatever.

      • there is a link to the open bug report in my OP,
      • the open bug report (from five years ago) includes a patch.
      • there have been no releases of AppConfig since that bug report was made.

      It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
        Given it's in core, definitely look into submitting it to p5p; perhaps you might offer to adopt the module as well, if it's important to you. The perlhack section on patching Perl will be a helpful reference. I suggest also watching mjd's Mailing List Judo talk for some very useful hints on managing your p5p experience to your advantage.
Re: Best way to deal with a bug in a CORE Module
by taint (Chaplain) on Dec 03, 2013 at 04:14 UTC

    While I am quite sure boftx already knows this. It might be well worth repeating, for those that don't, and ask themselves the same question;

    From PAUSE

    Taking over

    So there's a module on CPAN that has a critical bug, lacks some features, or is generally under-maintained and you would like to step in?

    It's great that you want to help out and we, the PAUSE admins, really don't want to create any unnecessary barrier to getting involved with an existing module (or distribution) on CPAN. There are, however, some precautions we have to take. The following paragraphs outline the reason for these precautions and the steps you have to take. Please read them carefully.

    The majority of modules on CPAN has active maintainers. If the maintainer didn't answer the ticket you created in the request tracker, maybe she doesn't know about the CPAN ticketing system yet? Or she's just very busy this week and will get back to you in due time. The best way of helping out is to talk to the current maintainer about what you can do. Getting the PAUSE admins involved is only a last resort!

    In some circumstances, we can grant co-maintenance permissions to you or others if the current maintainer of a module has entirely disappeared. You have to understand that is not a decision we make lightly. We are essentially giving write access to somebody else's work to third parties without explicit consent from the missing author. Since almost all code on CPAN has a free license, this is likely unproblematic from a legal point of view, but any violation of a contributor's trust in the PAUSE/CPAN mechanisms is a serious blow against the work of everybody who contributes to CPAN. For this reason, we try to tread very lightly, make the least possible use of the administrative privileges and attempt to protect voluntary contributors like yourself or the author of the module at hand from any unnecessary burden.

    You have to realize that the author has probably invested a signficiant amount of time into writing the code in the first place and then gone through the additional work of making it available to others via CPAN free of charge. Therefore, it is crucial to be very polite when asking him or her for co-maintenance permissions. Politeness, however, does not suffice. Particularly when maintaining a module for which you received co-maintenance permissions from the admins (as opposed to being appointed by the author himself), you are *required* to respect the work and design of the author. A common fallacy is that people think they are much better programmers than their predecessors and that entitles them to judge others code quality and refactor everything. Whether or not your style is "better" is entirely irrelevant as it is not your code. Do not be arrogant, be respectful and tread lightly!

    If you published your code to CPAN, then went on a hiking vacation (or to hospital) for a couple of weeks only to see that somebody took over, completely changed the design, and generally wreaked havoc, you would probably be rightfully upset and lose the good will that made you contribute in the first place. In order to prevent from happening, please go through the following steps and remember to be respectful all along:

    Use the rt.cpan.org request tracker to submit a bug report. If the module's documentation lists another request tracker, try that instead.

    Try to reach the author via mail. At the very least, try PAUSE_ID@cpan.org, any mail address the author listed on his search.cpan.org/~PAUSE_ID page, and any mail address that's listed in his or her module documentation. If there's even a mailing list, don't forget that either.

    Search the web for other ways of contacting the author. Send more mail. Try posting in public places such as your use.perl.org journal, perlmonks.org or other forums about your looking for the author.

    Wait for *at least* several weeks. Remember, the author might be on vacation, ill, or simply busy.

    Always keep modules@perl.org in the picture. Send us a copy of your mails to the author. After a reasonable period of waiting, send another mail to the list explaining how you tried to contact the author and pointing at the proof thereof. Do not forget to include your PAUSE ID and that of the original module author in this mail.

    Usually, after all this hassle, we are reasonably quick at assigning co-maintenance permissions, but don't hold your breath, we're only human after all. Most requests won't even get here as many authors who moved on and don't maintain their modules any more are very happy to see them taken care of and will assign (primary or) co-maintenance permissions after you've tracked them down and asked nicely.

    Good luck and thanks for stepping up.

    This document is mirrored on CPAN as CPAN/modules/04pause.html.

    Best wishes.

    --Chris

    #!/usr/bin/perl -Tw
    use Perl::Always or die;
    my $perl_version = (5.12.5);
    print $perl_version;

      Thanks for posting that, taint. I am already aware of it, and will probably wind up going down that path as my examination of AppConfig doesn't lead me to think that I can come up with a simple work-around short of applying the patch posted in the bug report.

      If I do decide to follow that path, it will be for the purpose of being granted co-maintainer status for the sole intent of applying that patch (giving proper credit, of course.) I haven't yet examined the other bugs in detail, so I don't know if those are ones that I can deal with at this time.

      It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
        Yea, as noted. I was sure you already knew that.

        As to "Taking Over". Things are beginning to look a lot like your sig:
        "It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.". :P

        But then, again. You'll be a hero in the eyes of all those who have had to mess around with it, in it's current shape. :)

        Best wishes.

        --Chris

        #!/usr/bin/perl -Tw
        use Perl::Always or die;
        my $perl_version = (5.12.5);
        print $perl_version;