p5pfaq - The perl 5 porters FAQ
The porters are the group of volunteers who develop Perl 5, working on any aspect of Perl, including code, testing, and documentation. There is no formal membership and anyone can participate, working as much as they desire and contributing what they can.
Initially, the name signified the group of people who ported the Perl 5 codebase to new platforms. The name has stuck around despite Perl taking over almost every platform people care to run it on.
The [email protected] mailing list is, briefly, for all topics related to the development of the Perl 5 language and the perl 5 interpreter. It's for reporting and fixing bugs, working towards the next version of perl 5, and improving the overall quality of the Perl 5 language.
The list receives a number of automatic emails. These include reports RT (http://rt.perl.org), smoke test failure reports, and messages from the perlthanks utility (which we encourage you to use).
The list is for the development of the perl codebase. If it's not related to developing the codebase, it probably doesn't belong on the list. For example, these thing should not be on the list:
* Announcements about events related to Perl
* Questions about programming Perl
* Questions covered in the Perl FAQ
* SpamThere are not many rules. However, Larry's advice from perlstyle apply just as well here as it does to Perl programming:
* Be consistent
* Be niceThe established medium for messages is plain text. If your email client wants to send things in HTML, please try and discipline it.
There are actually two rules:
1. Larry is always by definition right about how Perl should behave.
2. Larry is allowed to change his mind about any matter at a later date, regardless of whether he previously invoked Rule 1.Larry Wall is a "benevolent dictator", meaning he mostly lets development progress without interference, but in the rare cases where people cannot agree, everyone agrees that Larry is the final authority. When someone invokes "Rule 1", they are saying "Larry has decided, and that's how it is going to be".
Yes, there is, and it's at http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/.
If you want to receive all the messages but batched into a single mail per day, you can subscribe to <[email protected]> instead; send mail to <[email protected]>. Be warned that replying to messages from the digest may end up messing up threading on things like the web archive - at least set your outgoing Subject header to the subject of the individual message you're replying to.
Send mail to [email protected], and await a response. Once you reply to the response, you'll be unsubscribed.
If that doesn't work, find your subscription address - it'll be in the Return-Path header of any mails from p5p to you. If that's [email protected], send mail to [email protected].
Send mail to [email protected]. To specify [email protected] as your subscription address, send mail to [email protected].
Every message you get from perl5-porters will have an autogenerated Return-Path line. For instance: [email protected]
The number in the middle, 5523, is the sequence number. To get the message with a particular sequence number mailed to you, send mail to [email protected].
To a range of messages mailed to you in a digest, for instance, the messages with sequence numbers from 4902 to 4950, send mail to [email protected]. You may request a maximum of 100 messages in a single digest.
More general help on list management can be retrieved by sending a mail to [email protected].
Uh, you're reading it, aren't you? Oh well, life is strange. Send mail to [email protected] and you'll receive a copy.
It's also in the perlfaq Github repository at http://github.com/briandfoy/perlfaq/blob/master/p5pfaq.pod
First, are you sure it's a bug in Perl itself, not just a bug in your code? Take the problem out of the context of your current program and write a short test program to reproduce it - as short as you possibly can. It's far easily to clearly detect a Perl bug if it's demonstrated in 5 lines of code, rather than buried somewhere in the middle of a 500-line program.
Next, do we already know about it? Check with the bug ticketing system at http://rt.perl.org/perlbug/.
It's always worth getting someone else to look it over and confirm that this really is a Perl bug, not just a thinko. If there's nobody around to do that, consider asking on the comp.lang.perl.misc or comp.lang.perl.moderated newsgroups.
Now, if you've really got a bug, type perlbug at your prompt and follow the instructions. It really helps us if you provide:
* your demonstration code
* the actual output you got, including warnings and error messages
* what you think you should have got,
* the part of the Perl documentation that makes you think that.Follow the list for a few weeks or months to get an idea of what goes on, and see if anything pops up that you're interested in. Occasionally someone will request a fix, and that's your chance!
If there doesn't appear to be anything you want to or are able to do, have a look in your Perl source kit: you'll find the (outdated) file pod/perltodo.pod--some of the items there are being worked on, so check back-issues of p5p. Look also at the end of the last perldelta.pod. Furthermore, you don't need to be an expert programmer: anyone can help with proof-reading, correcting and expanding the documentation, for instance. There's certainly a place for anyone who truly wants to get involved, and over time, you'll find it.
You should also read perlhack.pod, Porting/pumpkin.pod and Porting/patching.pod--these will tell you how to create and submit patches, as well as some more philosophical issues involved in patching Perl. To summarise:
* diff -ruN perl-current perl-patched > patch and append that
verbatim, preferably not as an attachment, to your post.
* Drastic changes to the syntax and/or operation of Perl are
going to be viewed with a lot of suspicion. Start small.
* Patches speak louder than words. Having ideas is good, but
taking the time to implement them will improve their credibility.
* At least one person will think your patch sucks. It's better to
let the code stand on its own merits than get into arguments.I've created a patch, but I'd like someone to check it over before I post it to the list. What should I do?
The first thing you should do is relax! We don't bite, and we appreciate people who want to help. Just go for it. However, if you're still worried about whether you should send the patch, email the relevant pumpking for the area you're patching, or one of the referees.
Perl is available inside a git repository. Git ( http://git-scm.com/ ) is a popular, distributed and open-source version control system. To learn more about checking out the Perl source using git see:
http://perl5.git.perl.org/perl.git/blob/HEAD:/pod/perlrepository.pod
If you already know how to use git, you can access the repository here:
http://perl5.git.perl.org/perl.git/
There is also a mirror of the repository on Github at http://github.com/github/perl/ but this lags behind.
Perl was formerly kept in a Perforce repository. When a change was made on the Perforce server, a patch was generated and placed in the Archive of Perl Changes. This is located at http://ftp.linux.activestate.com/pub/staff/gsar/APC/
The directory diffs/ contains patches against the latest release.
All of this has probably become irrelevant after the switch to git.
perl-current used to be the very latest Perforce snapshot of Perl. Now the recommended way is to use git.
"bleadperl" is the term that is now used for the git blead branch.
maintperl are the various maintenance branches:
remotes/origin/maint-5.004
remotes/origin/maint-5.005
remotes/origin/maint-5.10
remotes/origin/maint-5.6
remotes/origin/maint-5.8One for each released version of Perl.
You didn't read Porting/pumpkin.pod, did you? :) A pumpking is the person who holds the patch pumpkin, the responsibility for coordinating patches on a specific area.
The pumpking is the person who holds the patch pumpkin for Perl itself, what other projects call the "release engineer". The pumpking for each version of Perl is listed in the perlhist documentation.
While the pumpking has the overall responsibility for delivering the stable releases of perl, the release manager manages the regular releases of the development versions. The release manager handles the short term development cycles. They care out their duties under the guidance and supervision of the pumpking.
There are never enough Acme:: modules in core.
Participate through Github:
http://github.com/briandfoy/perlfaqYou can also send comments to [email protected] .
The FAQ was last updated March 31, 2010.
Its primary author was Simon Cozens. It's currently maintained by Rafael Garcia-Suarez and James Laver.