]> git.vpit.fr Git - perl/modules/Scope-Upper.git/commitdiff
Add a CONTRIBUTING guidelines file
authorVincent Pit <vpit@cpan.org>
Sun, 26 Mar 2023 12:51:59 +0000 (14:51 +0200)
committerVincent Pit <vpit@cpan.org>
Sun, 26 Mar 2023 13:18:27 +0000 (15:18 +0200)
CONTRIBUTING [new file with mode: 0644]
MANIFEST

diff --git a/CONTRIBUTING b/CONTRIBUTING
new file mode 100644 (file)
index 0000000..ddc995a
--- /dev/null
@@ -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.
index 8885f4baeb47166555996e04ec36e3eefb5c907e..f3c0edff23a8bae6380eb012809db79f46ef1c93 100644 (file)
--- a/MANIFEST
+++ b/MANIFEST
@@ -1,3 +1,4 @@
+CONTRIBUTING
 Changes
 MANIFEST
 META.json