Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Fetching contributors…
Cannot retrieve contributors at this time
70 lines (46 sloc) 2.35 KB
Patching policy for perl5i.
For the really impatient:
* Rule 1: When in doubt, open a ticket.
Found a bug? Not sure if its a bug or a weird feature? Have an idea?
Found something unpleasent? Had trouble using something? Open a ticket.
Don't worry, we won't yell at you. We'd rather get 10 duplicates than
lose one good report because somebody wasn't sure.
* We prefer if you use github, but you can always email a patch
* Don't know if your code is up to our standard? Send it in and
we'll work it out.
* perl5i is about making Perl 5 better. A good rule of thumb is if
it takes more than one line to do a simple thing, you might be on to
something. If a newbie asks a simple question and the "right answer"
takes a full page, you've probably found a candidate for perl5i.
Here's the preferred way to make a patch:
0) We'd rather you participate than follow all the rules, especially
if its your first patch. Don't worry, be crappy.
1) Put an issue in the tracker for your problem. Then it can be
discussed before you put a whole lot of effort into it.
1a) If its a bug, report the bug BEFORE work on it. This ensures the
bug gets reported. Mention that you're working on it.
1b) If its a feature, we like to hear about your idea even if
you don't have a patch.
2) You can either work from the CPAN version or the repository.
We'd prefer you worked from the repository.
2a) Ideally, make a fork on github and work on that.
3) DO add any new dependencies in Build.PL
3a) If you're not sure what version to depend on, pick the version
you have installed. That's safest.
4) DON'T update MANIFEST. Its automated and will just cause
5) DON'T update Changes. It will cause conflicts when merging.
The release manager will handle it.
6) DO write tests. Otherwise the release manager has to.
7) DO write documentation. Otherwise the release manager has to.
8) Commit ONE THING AT A TIME. Preferrably use a branch for each
feature. It makes it much easier to integrate.
9) You can either send patches to or
(preferred) issue a github pull request.
Thanks for patching!
Jump to Line
Something went wrong with that request. Please try again.