From: Vincent Pit Date: Sun, 26 Mar 2023 12:51:59 +0000 (+0200) Subject: Add a CONTRIBUTING guidelines file X-Git-Tag: v0.34~4 X-Git-Url: http://git.vpit.fr/?a=commitdiff_plain;h=20d82307d02d72e3b5e73cfa40588b3af52d81d4;p=perl%2Fmodules%2FScope-Upper.git Add a CONTRIBUTING guidelines file --- diff --git a/CONTRIBUTING b/CONTRIBUTING new file mode 100644 index 0000000..ddc995a --- /dev/null +++ b/CONTRIBUTING @@ -0,0 +1,39 @@ +Contributing guildelines for the Scope-Upper distribution + +Patch submissions guidelines : +- Patches VERY MUCH SHOULD be generated with "git format-patch". + If that's really not possible, make sure your patches apply cleanly in the + distribution directory. +- Single patches MUST be submitted to the bugtracker. + Open a ticket and add your patch as an attachment. +- Series of patches CAN be submitted as a public feature branch. + You can clone the directory wherever you want and point me to your remote + branch as long as I don't need to log in. + +C/XS-related guidelines : +- C code MUST be kept ANSI-compliant. + Older perl versions may have been built with a C compiler that does not + support C99 features (plus they are mostly useless except for restrict). + In particular, this means no C99 comments, no mixed declaration and code, + and no C++ void* casts. +- XS code MUST be buildable with any perl matching the META requirements. + If needed, wrap your code around with the XSH_HAS_PERL(x, y, z) macro. + +Tests-related guidelines : +- Patches MUST be tested before being sent. + Make sure the distribution builds and tests correctly. +- Patches that add version-specific code MUST be tested with at least + one perl release matching each version interval. + That is, if you add new code specific to perl 5.34 and above, then you + have to test it with a pre-5.34 perl (e.g. 5.32) and a post-5.34 perl + (e.g. 5.34). +- C/XS patches MUST be tested with a threaded perl regardless of how much you + dislike perl threads. + Testing with a threaded perl makes sure your code can build in many more + situations. Memory issues are also more easily spotted. +- Bugfixes SHOULD come with a regression test. + Add it to an existing .t file or create your own. + +What you don't need to do : +- DON'T update the Changes file. +- DON'T run author tests. diff --git a/MANIFEST b/MANIFEST index 8885f4b..f3c0edf 100644 --- a/MANIFEST +++ b/MANIFEST @@ -1,3 +1,4 @@ +CONTRIBUTING Changes MANIFEST META.json