Relinquishing Maintenance of Core Modules
I am the current maintainer of several core Perl 5 modules as well as some I have developed myself. However, I am no longer able to devote effort into maintaining these. As such, I would like to transfer ownership/responsibility to whoever would like to volunteer. The core modules are: threads threads-shared Thread-Queue Thread-Semaphone Their github repositories are: Dual-Life/threads-shared Dual-Life/Thread-Queue Dual-Life/threads Dual-Life/Thread-Semaphore Additional modules I maintain include: Thread-Cancel Thread-Suspend Bundle-Thread Object-InsideOut Math-Random-MT-Auto and their corresponding github repos: jdhedden/Thread-Cancel jdhedden/Thread-Suspend jdhedden/Bundle-Thread jdhedden/Object-InsideOut jdhedden/Math-Random-MT-Auto It's been a grand journey. Jerry D. Hedden
Re: Perl Modules in GitHub
That just what I'm looking for, Leon. Would you please add me to that organization (jdhedden) so that I can add the dual-life modules I have to it? Thanks. On Tue, Mar 29, 2016 at 10:07 AM, Leon Timmermans <faw...@gmail.com> wrote: > On Tue, Mar 29, 2016 at 5:21 AM, Jerry D. Hedden <jdhed...@cpan.org> > wrote: > >> I maintain server Perl modules on CPAN: >> http://search.cpan.org/~jdhedden/ Some of the modules are part of the >> core Perl distribution; some are my own. I want to add them to GitHub. Is >> there preferred organization, account, methodology for doing this? I would >> think there is a better way than just putting them under my own GitHub >> account, particularly as this would complicate matters if the time should >> come when someone else would need to take over their maintenance. >> > > AFAIK the perl group is not meant as a community development platform > (most obviously perl/perl is only a mirror), but more as communication to > the outside world The Perl Toolchain gang is quite functional at what it's > trying to do, but I don't think think that enlarging that umbrella is a > good idea organizationally. I do think it may be a good idea to have an > organization for non-toolchain dual-life modules (in fact, I just took the > liberty of creating exactly such an organization). > > Leon > >
Re: Perl Modules in GitHub
Okay, I see that GitHub allows me to create organizations which I presume is what you're referring to as groups. Are there existing organizations for which adding the core Perl Modules (threads, threads::shared, etc.) would be appropriate? On Mon, Mar 28, 2016 at 11:23 PM, Dean Hamstead <d...@fragfest.com.au> wrote: > Github allows you to create "groups" which can own modules. > > You can then add people to those groups as you see fit. > > > > > > Dean > > > > > On 2016-03-29 14:21, Jerry D. Hedden wrote: > > I maintain server Perl modules on CPAN: > http://search.cpan.org/~jdhedden/ Some of the modules are part of the > core Perl distribution; some are my own. I want to add them to GitHub. Is > there preferred organization, account, methodology for doing this? I would > think there is a better way than just putting them under my own GitHub > account, particularly as this would complicate matters if the time should > come when someone else would need to take over their maintenance. > >
Perl Modules in GitHub
I maintain server Perl modules on CPAN: http://search.cpan.org/~jdhedden/ Some of the modules are part of the core Perl distribution; some are my own. I want to add them to GitHub. Is there preferred organization, account, methodology for doing this? I would think there is a better way than just putting them under my own GitHub account, particularly as this would complicate matters if the time should come when someone else would need to take over their maintenance.
Re: Consensus on MakeMaker vs. Module::Build vs. Module::Install?
For the modules I put on CPAN, I use ExtUtils::MakeMaker/Makefile.PL because it is universally installed on all Perl versions that I support, and I have not found a need to migrate to something else.
Re: Weekend entertainment
David Golden wrote: I would rather see the author withdraw it voluntarily. Thomas Klausner wrote: I would suggest renaming the dist to Acme::Lingua::NigerianSPAM, which makes it clear that the author is not mocking the country and/or people of Nigeria, but only the very annoying spammers who deserve all the mocking they can get. Capital idea. Hope the author concurs.
Re: Weekend entertainment
David Landgren wrote: I wanted to share this... Some people have no sense of humour. This came up on the cont...@perl.org queue. (I shall compose a message saying Acme is fun, etc. etc. Can anyone point me to other similar Acme modules to put this in context?) David Golden replied: I think the module is offensive -- which is not inconsistent with it trying to be funny Funny and offensive is sometimes a fine line. I'm not saying it needs to be yanked -- I don't support censoring bad thoughts. I would rather see the author withdraw it voluntarily. Even in Acme, I'd rather see the Perl community trying to be inclusive and not make jokes at anyone's expense. I think the module is funny, and I don't find it offensive at all. To whom is it offensive? Nigerians that are ashamed of what their fellow countrymen are doing? Well, they should be, and should put a stop to it. Consider Jeff Foxworthy making fun of rednecks. How is that different? Nearly all humor offends someone. F*** 'em if they can't take a joke. Go out and by a thicker skin. As the module doesn't border on a hate crime, I see not reason to even suggest that the author consider a voluntary withdrawal. People do remember Alias' ill-considered Acme::Playmate talk, right? (And his very responsible apology afterwards, too) http://geekfeminism.wikia.com/wiki/Acme::Playmate_talk Again, a few people that can't take a joke. You can't please all the people all the time. (Just my opinion. Take it with a big grain of salt.) BTW, here's a joke for you: Where do you find a turtle with no legs? Right where you left it! Ha Ha I'm sure I'll piss off a few animal lovers with that one. ;)
Re: Why you don't want to use /dev/random for testing
There are other options too, depending on your needs. The Math::Random namespace has tons of these, including one that I've worked on (Math::Random::ISAAC) and some others I've toyed with, notably the Mersenne Twister (Math::Random::MT) and TT800 algorithms (related to the Mersenne Twister; see Math::Random::TT800) Math::Random::MT::Auto another PRNG module. It uses a variety of random data source for seeding, and has a insuperably long period. (But as with any PRNG, not cryptographically suitable.) If you need random data, you can also get it from interrupt timings. See Math::TrulyRandom for details. The Math::Random::MT::Auto POD also lists several truly random data sources.
Re: How to best detect availability of C compiler in Makefile.PL?
On Tue, Oct 13, 2009 at 6:17 AM, O. STeffen BEYer ost...@gmail.com wrote: what would be the best way to detect whether a working C compiler is available at build time of a module (i.e., in Makefile.PL)? See the Makefile.PL for the 'threads' module. I have reused this technique in several other modules and it works well.
Re: how to set $VERSION throughout distribution
Because then you have to update more than one module. Shawn's Programming Rules #5 http://www.perlfoundation.org/perl5/index.cgi?shawn_h_corey#shawn_s_programming_rules: 5. If you have the same data in two places, they will get out off sync. Write the code to detect and correct this now, because when it happens, it will be too late. You just need something to keep them in sync. I have a script that sets all the version and double-checks them (and does so much more as well) before I make a release to CPAN. package Workflow; use Workflow::VERSION; $Workflow::VERSION = $Workflow::VERSION::VERSION; This sort of strategy caused problems with the CPANPLUS module code awhile back in that the 'cpan-r' command showed its submodules to have no version numbers. Not sure if that's all been fixed now, but it did illustrate to me that trying to set versions via a version module is not a robust scheme.
Re: how to set $VERSION throughout distribution
I use the three number form: $VERSION = q(v1.2.3); This may cause problems because it makes $VERSION a string, namely, v1.2.3. This prohibits numeric version comparisons which is the norm. It also means your CPAN modules will get called something like Mod-Name-v1.2.3.tar.gz which is also non-standard.
Re: Test Failures - XS, does not match bootstrap parameter and version objects
The error message says it all: XS object version v1.0.6 does not match bootstrap parameter 1.0.6 Note the 'v' in the first version statement and the lack in the second. This is just one reason I don't use anything but single decimal point versions (e.g., 1.23), and never use version objects. In fact, I even make sure my versions don't end in 0 either - i.e., I go from 1.09 to 1.11. I know there's a right way to probably do all this, but it always seems there a catch somewhere with older perls, CPAN or something else. Therefore, I just avoid all the headaches and hassles with the above scheme. On Tue, Jul 28, 2009 at 12:37 PM, Jonathan Yujonathan.i...@gmail.com wrote: Hi: I seek the wisdom of any other module authors that might have come across this problem. Recently, I uploaded a new version of Math::Random::ISAAC::XS and ran into a *lot* of regressions. I've looked at the diff and I didn't really change all that much, except for removing some things from Recommends. The smokers nonetheless output something that I can't reproduce, and I'm not sure if it has to do with my use of the 'version' pragma, or if the systems in question are using an older version than I test with. In at least one report, the version seems to be recent, so I'm not sure if it's a new issue: version 0 0.76_06 I get plenty of failing tests: http://www.cpantesters.org/distro/M/Math-Random-ISAAC-XS.html#Math-Random-ISAAC-XS-1.0.6 Here is the diff between my last (100% PASS) version, 1.05, and the latest version, which has a lot more failures than I'd like: http://search.cpan.org/diff?from=Math-Random-ISAAC-XS-1.0.5to=Math-Random-ISAAC-XS-1.0.6 Any insight that the module-authors can provide would be greatly appreciated. Does this have to do with the latest version pragma? Maybe I should also agree that it's considered a Bad Thing and move to using the older, more Perlish version numbers :(
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.52
Michael G Schwern wrote: This is a release of ExtUtils::MakeMaker, the thing that runs your Makefile.PL. Bug Fixes * maybe_command() will recognize Windows executables in /cygdrive on Cygwin [rt.cpan.org 16375] (PJF) The implemented tests don't work if the drive prefix (cygdrive) is changed by the user (like I do :). I have submitted a bug report on this along with a patch (also attached here). Thanks. Bug report: https://rt.cpan.org/Ticket/Display.html?id=46585 cygwin.patch Description: Binary data
Re: Testing on blead
Johan Vromans wrote: We all love the CPAN testers and the results publised at http://testers.cpan.org. Except when failure reports reflect problems in a particular tester's environment, and not problems with the modules being tested. (But that goes without saying, right?) But recently I suddenly saw a big load of failures in one of my packages. All these failures were for 5.11.0. Now, 5.11.0 is a development version, and a moving target. A test failure with blead reveals often more about blead than about the tested package. I routinely report tests against blead. I don't see failures often, and when I do, they usually reflect some new change in Perl that requires a subsequent change in the module. When I encounter such cases, I try to figure out a patch and then report it as bug (along with the patch) against the affected module. So, on one hand, it is a good thing that packages are being tested with blead versions. On the other hand, when users want to find out if a package is usable they're only interested in released versions of perl. What are your ideas about this? Should blead test results be separated from the other results? I agree they should be segregated. However, they should also be reported to the module's maintainers so they can fix things appropriately.
Re: Maintainer mode
You don't need to make these tests run for the end user to get the point.
All of my dists (should) ship with a pod.t and pod-coverage.t that only runs
in maintainer mode.
How do you do that, by the way? How do you set it up so the test
suite knows it's you and not an end-user?
Environment variable:
use Test::More;
if ($ENV{RUN_MAINTAINER_TESTS}) {
plan 'tests' = 3;
} else {
plan 'skip_all' = 'Module maintainer tests';
}
How to require threads? (was FAIL Thread-Queue-2.04 darwin-2level 9.1.0)
If you look through the failure report below, you'll find
the relevant issue:
ERROR: This Perl not built to support threads
This is purposefully generated in Makefile.PL:
use Config;
BEGIN {
die(ERROR: This Perl not built to support threads\n)
if (! $Config{'useithreads'});
}
Thus, there is no failure; there is a lack of meeting a
prerequisite. As such, trying to install this module should
result in an UNKNOWN and not a FAIL.
My question is how to code Makefile.PL to require a Perl
version built with ithreads, but not have it be reported as
a failure?
On Feb 20, 2008 5:11 AM, [EMAIL PROTECTED] wrote:
This distribution has been tested as part of the cpan-testers
effort to test as many new uploads to CPAN as possible. See
http://testers.cpan.org/
Please cc any replies to [EMAIL PROTECTED] to keep other
test volunteers informed and to prevent any duplicate effort.
--
Dear Jerry D. Hedden,
This is a computer-generated report for Thread-Queue-2.04
on perl-5.8.8, created automatically by CPAN-Reporter-1.0602
and sent to the CPAN Testers mailing list.
If you have received this email directly, it is because the person testing
your distribution chose to send a copy to your CPAN email address; there
may be a delay before the official report is received and processed
by CPAN Testers.
Thank you for uploading your work to CPAN. However, it appears that
there were some problems with your distribution. If these results are
not what you expect or if you would like to learn how to avoid FAIL
reports for missing dependencies, unsupported operating systems, etc.,
please consult Notes for CPAN Authors on the CPAN Testers Wiki:
http://cpantest.grango.org
Sections of this report:
* Tester comments
* Program output
* Prerequisites
* Environment and other context
--
TESTER COMMENTS
--
Additional comments from tester:
[none provided]
--
PROGRAM OUTPUT
--
Output from '/opt/local/bin/perl Makefile.PL INSTALLDIRS=site
LIB=/Users/naha/local/lib/perl5 PREFIX=/Users/naha/local':
ERROR: This Perl not built to support threads
BEGIN failed--compilation aborted at Makefile.PL line 8.
--
PREREQUISITES
--
Prerequisite modules loaded:
No requirements found
--
ENVIRONMENT AND OTHER CONTEXT
--
Environment variables:
LANG = ja_JP.UTF-8
LD_LIBRARY_PATH = /opt/local/lib:/Users/naha/local/lib:
LIB = /Users/naha/local/lib
PATH =
/Users/naha/bin:/Users/naha/plagger:/opt/local/bin:/Users/naha/local/bin:/usr/local/mysql/bin:/opt/local/apache2/bin:/Users/naha/downloads/Django-0.96/django/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/bin:/Developer/SDKs/flex/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
PERL5LIB =
/Users/naha/local/lib/perl5:/Users/naha/local/lib/perl5/site_perl
PERL5_CPANPLUS_IS_RUNNING = 19963
PERL5_CPAN_IS_EXECUTING =
/Users/naha/.cpan/build/Thread-Queue-2.04-Jr_aHf/Makefile.PL
PERL5_CPAN_IS_RUNNING = 19963
PERL_AUTOINSTALL = --defaultdeps
SHELL = /bin/zsh
TERM = xterm-color
TMPDIR = /var/folders/HW/HWVMfy3XECOWYx-DdhwifU+++TI/-Tmp-/
Perl special variables (and OS-specific diagnostics, for MSWin32):
$^X = /opt/local/bin/perl
$UID/$EUID = 501 / 501
$GID = 20 80 79 101 81 98 20
$EGID = 20 80 79 101 81 98 20
Perl module toolchain versions installed:
Module Have
--- --
CPAN1.9205
Cwd 3.2701
ExtUtils::CBuilder 0.22
ExtUtils::Command 1.13
ExtUtils::Install 1.44
ExtUtils::MakeMaker 6.36
ExtUtils::Manifest 1.51
ExtUtils::ParseXS 2.19
File::Spec 3.2701
Module::Build 0.2808
Module::Signature n/a
Test::Harness 3.09
Test::More 0.74
YAML0.66
YAML::Syck 1.04
version 0.74
--
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=darwin, osvers=9.1.0, archname=darwin-2level
uname='darwin joe-nahas-macbook-pro.local 9.1.0 darwin kernel version
9.1.0: wed oct 31 17:46:22 pdt 2007; root:xnu-1228.0.2~1release_i386 i386 '
config_args='-des -Dprefix=/opt/local -Dccflags=-I'/opt/local/include'
-Dldflags=-L/opt/local/lib -Dvendorprefix=/opt/local -Dcc=/usr/bin/gcc-4.0'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Re: How to require threads? (was FAIL Thread-Queue-2.04 darwin-2level 9.1.0)
If you look through the failure report below, you'll find
the relevant issue:
ERROR: This Perl not built to support threads
This is purposefully generated in Makefile.PL:
use Config;
BEGIN {
die(ERROR: This Perl not built to support threads\n)
if (! $Config{'useithreads'});
}
Thus, there is no failure; there is a lack of meeting a
prerequisite. As such, trying to install this module should
result in an UNKNOWN and not a FAIL.
My question is how to code Makefile.PL to require a Perl
version built with ithreads, but not have it be reported as
a failure?
Vincent Pit wrote:
You can let it die with OS unsupported as the error message.
This appears to be a CPANPLUS specific solution (which is a
start, at least). Is there anything else, hopefully more
general?
Re: How to require threads? (was FAIL Thread-Queue-2.04 darwin-2level 9.1.0)
Thanks for the responses. I went with the following:
In the following modules, I added 'threads' as a
prerequisite:
threads::shared
Thread::Queue
Thread::Semaphore
Thread::Cancel
Thread::Suspend
In the Makefile.PL for 'threads', I used (per Dave's
suggestion):
use Config;
BEGIN {
die(OS unsupported: ERROR: This Perl not built to support threads\n)
if (! $Config{'useithreads'});
}
This should result in NA's for any attempts to install
'threads' on non-threaded Perls, and no reports at all for
the other modules because their 'threads' prerequiste is not
met.
Re: How to require threads? (was FAIL Thread-Queue-2.04 darwin-2level 9.1.0)
this however clashes with the forks.pm module: forks.pm is supposed to supply an ithreads compatible API, without having to have a threads enable perl. Interesting, but I'm not going to attempt to support the 'forks' module (at least not just yet). Looking over its docs, I found that if users really want to, they can install 'forks' as though it were 'threads'. They could then force the installation of whatever Thread::* modules they then want to use.
Re: How best to state VERSION
There's a million and one opinions on this. Here's mine. I only use the #.## format, and never use a zero for the last digit. Therefore, I always start with 1.01, and wouldn't use something like 1.10, (i.e., I'd go from 1.09 to 1.11). I've never had any problems with this formating, and it works with everything. All other formats have pros and cons. Just my $0.02. On Feb 17, 2008 1:59 PM, Geoffrey Leach [EMAIL PROTECTED] wrote: I recently had my hand slapped (in the nicest possible way!) for this in the principal module of a CPAN submission. use version; our $VERSION = qv(1.0.0); # Also appears ... our $VERSION = 1.; worked just fine. Is there a workaround that allows the use of qv, short of using Module::Build?
Re: How to recognize modules that needs compilation?
Gabor Szabo wrote: I would like to create a list of modules that need compilations as opposed to those that are pure perl Is checking for a file with .xs .c or .h extension in the distribution the correct thing to do? I think it would cover nearly all cases.
Who controls svn.perl.org?
Who do I need to contact to get access permission on svn.perl.org so I can add the 'threads' and 'threads::shared' modules to it? Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: Who controls svn.perl.org?
Jerry D. Hedden wrote: Who do I need to contact to get access permission on svn.perl.org so I can add the 'threads' and 'threads::shared' modules to it? Andy Lester wrote: I recommend using Google Code hosting at code.google.com instead. Setup is trivial, as is adding people to the project. Both of those require human intervention if you host it on svn.perl.org. For my own modules, I might consider it, but for core modules, I feel they should go somewhere more 'official'. But I see from http://www.perlmonks.org/?node_id=606275 that you've asked and been responded to there about this. I wonder why you still want svn.perl.org. You must be mistaking me for someone else on this point. I am not referenced on that node. Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather
Re: supporting older perls
Greg Matheson wrote: How do you find out what can be done in older perls? Andy Armstrong wrote: Is it not possible to build 5.6.2? Archaeology: this seems to be the birth of use constant: http://backpan.hexten.net/authors/id/P/PH/PHOENIX/constant-0.01.readme 5.6.2 is available here: http://search.cpan.org/~rgarcia/perl-5.6.2/ I built it under Solaris and use it for testing my modules. Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
RE: Assume Co-Maintainership of Mail-Webmail-Gmail
Original Message Subject: Re: Assume Co-Maintainership of Mail-Webmail-Gmail From: Shlomi Fish [EMAIL PROTECTED] Date: Fri, March 10, 2006 6:41 am To: modules@perl.org Cc: Perl Module-Authors module-authors@perl.org It's been over a month since I sent this. Why didn't I receive a reply? You have to contact the 'owner' directly. Only the owner can make you a co-maintainer. This mailing list does not directly affect ownership. On Monday 06 February 2006 00:05, Shlomi Fish wrote: I'd like to become co-maintainer of the Mail-Webmail-Gmail module: http://search.cpan.org/dist/Mail-Webmail-Gmail/ Has been unmaintained since April 2005, and is now broken due to the gmail interface change. I wrote and submitted a patch to fix it: http://rt.cpan.org/Public/Bug/Display.html?id=14540 However it was not applied since its submission. The author did not respond to my ping, and had not dealt with the incompatiblity change. Thus, please make my user on PAUSE (SHLOMIF) a co-maintainer of this module so I can upload a corrected version of it there.
