Commit | Line | Data |
48cb5b3a |
1 | =head1 NAME |
3c78fafa |
2 | |
48cb5b3a |
3 | perlpolicy - Various and sundry policies and commitments related to the perl core |
4 | |
5 | =head1 DESCRIPTION |
6 | |
7 | This document is the master document which records all written |
8 | policies about how the Perl 5 Porters collectively develop and maintain |
9 | the Perl core. |
10 | |
11 | |
fcf56c88 |
12 | =head1 MAINTENANCE BRANCHES |
13 | |
14 | =over |
15 | |
16 | =item * |
17 | |
18 | New releases of maint should contain as few changes as possible. |
19 | If there is any question about whether a given patch might merit |
20 | inclusion in a maint release, then it almost certainly should not |
21 | be included. |
22 | |
23 | =item * |
24 | |
25 | Portability fixes, such as changes to Configure and the files in |
26 | hints/ are acceptable. Ports of Perl to a new platform, architecture |
27 | or OS release that involve changes to the implementation are NOT |
28 | acceptable. |
29 | |
30 | =item * |
31 | |
32 | Documentation updates are acceptable. |
33 | |
34 | =item * |
35 | |
36 | Patches that add new warnings or errors or deprecate features |
37 | are not acceptable. |
38 | |
39 | =item * |
40 | |
41 | Patches that fix crashing bugs that do not otherwise change Perl's |
42 | functionality or negatively impact performance are acceptable. |
43 | |
44 | =item * |
45 | |
46 | Patches that fix CVEs or security issues are acceptable, but should |
47 | be run through the perl5-security-report@perl.org mailing list |
48 | rather than applied directly. |
49 | |
50 | =item * |
51 | |
52 | Updates to dual-life modules should consist of minimal patches to |
53 | fix crashing or security issues (as above). |
54 | |
55 | =item * |
56 | |
57 | New versions of dual-life modules should NOT be imported into maint. |
58 | Those belong in the next stable series. |
59 | |
60 | =item * |
61 | |
62 | Patches that add or remove features are not acceptable. |
63 | |
64 | =item * |
65 | |
66 | Patches that break binary compatibility are not acceptable. (Please |
67 | talk to a pumpking.) |
68 | |
69 | =back |
70 | |
71 | |
72 | =head2 Getting changes into a maint branch |
73 | |
74 | Historically, only the pumpking cherry-picked changes from bleadperl |
75 | into maintperl. This has...scaling problems. At the same time, |
76 | maintenance branches of stable versions of Perl need to be treated with |
77 | great care. To that end, we're going to try out a new process for |
78 | maint-5.12. |
79 | |
80 | Any committer may cherry-pick any commit from blead to maint-5.12 if |
81 | they send mail to perl5-porters announcing their intent to cherry-pick |
82 | a specific commit along with a rationale for doing so and at least two |
83 | other committers respond to the list giving their assent. (This policy |
84 | applies to current and former pumpkings, as well as other committers.) |
48cb5b3a |
85 | |
86 | =head1 CONTRIBUTED MODULES |
87 | |
88 | |
89 | =head2 A Social Contract about Artistic Control |
6ee623d5 |
90 | |
91 | What follows is a statement about artistic control, defined as the ability |
92 | of authors of packages to guide the future of their code and maintain |
93 | control over their work. It is a recognition that authors should have |
94 | control over their work, and that it is a responsibility of the rest of |
95 | the Perl community to ensure that they retain this control. It is an |
96 | attempt to document the standards to which we, as Perl developers, intend |
97 | to hold ourselves. It is an attempt to write down rough guidelines about |
98 | the respect we owe each other as Perl developers. |
99 | |
100 | This statement is not a legal contract. This statement is not a legal |
101 | document in any way, shape, or form. Perl is distributed under the GNU |
102 | Public License and under the Artistic License; those are the precise legal |
103 | terms. This statement isn't about the law or licenses. It's about |
104 | community, mutual respect, trust, and good-faith cooperation. |
105 | |
106 | We recognize that the Perl core, defined as the software distributed with |
107 | the heart of Perl itself, is a joint project on the part of all of us. |
aaa2bbb1 |
108 | From time to time, a script, module, or set of modules (hereafter referred |
6ee623d5 |
109 | to simply as a "module") will prove so widely useful and/or so integral to |
110 | the correct functioning of Perl itself that it should be distributed with |
111 | Perl core. This should never be done without the author's explicit |
112 | consent, and a clear recognition on all parts that this means the module |
113 | is being distributed under the same terms as Perl itself. A module author |
114 | should realize that inclusion of a module into the Perl core will |
115 | necessarily mean some loss of control over it, since changes may |
116 | occasionally have to be made on short notice or for consistency with the |
117 | rest of Perl. |
118 | |
119 | Once a module has been included in the Perl core, however, everyone |
120 | involved in maintaining Perl should be aware that the module is still the |
121 | property of the original author unless the original author explicitly |
122 | gives up their ownership of it. In particular: |
123 | |
48cb5b3a |
124 | =over |
125 | |
171407a0 |
126 | =item * |
127 | |
128 | The version of the module in the core should still be considered the |
129 | work of the original author. All patches, bug reports, and so |
130 | forth should be fed back to them. Their development directions |
131 | should be respected whenever possible. |
6ee623d5 |
132 | |
48cb5b3a |
133 | =item * |
134 | |
135 | Patches may be applied by the pumpkin holder without the explicit |
136 | cooperation of the module author if and only if they are very minor, |
137 | time-critical in some fashion (such as urgent security fixes), or if |
138 | the module author cannot be reached. Those patches must still be |
139 | given back to the author when possible, and if the author decides on |
140 | an alternate fix in their version, that fix should be strongly |
141 | preferred unless there is a serious problem with it. Any changes not |
142 | endorsed by the author should be marked as such, and the contributor |
143 | of the change acknowledged. |
144 | |
145 | =item * |
146 | |
147 | The version of the module distributed with Perl should, whenever |
148 | possible, be the latest version of the module as distributed by the |
149 | author (the latest non-beta version in the case of public Perl |
150 | releases), although the pumpkin holder may hold off on upgrading the |
151 | version of the module distributed with Perl to the latest version |
152 | until the latest version has had sufficient testing. |
153 | |
154 | =back |
6ee623d5 |
155 | |
156 | In other words, the author of a module should be considered to have final |
157 | say on modifications to their module whenever possible (bearing in mind |
158 | that it's expected that everyone involved will work together and arrive at |
159 | reasonable compromises when there are disagreements). |
160 | |
161 | As a last resort, however: |
162 | |
48cb5b3a |
163 | |
164 | If the author's vision of the future of their module is sufficiently |
165 | different from the vision of the pumpkin holder and perl5-porters as a |
166 | whole so as to cause serious problems for Perl, the pumpkin holder may |
167 | choose to formally fork the version of the module in the core from the |
168 | one maintained by the author. This should not be done lightly and |
c4f5d98d |
169 | should B<always> if at all possible be done only after direct input |
48cb5b3a |
170 | from Larry. If this is done, it must then be made explicit in the |
171 | module as distributed with Perl core that it is a forked version and |
172 | that while it is based on the original author's work, it is no longer |
173 | maintained by them. This must be noted in both the documentation and |
174 | in the comments in the source of the module. |
6ee623d5 |
175 | |
176 | Again, this should be a last resort only. Ideally, this should never |
177 | happen, and every possible effort at cooperation and compromise should be |
178 | made before doing this. If it does prove necessary to fork a module for |
179 | the overall health of Perl, proper credit must be given to the original |
180 | author in perpetuity and the decision should be constantly re-evaluated to |
181 | see if a remerging of the two branches is possible down the road. |
182 | |
183 | In all dealings with contributed modules, everyone maintaining Perl should |
184 | keep in mind that the code belongs to the original author, that they may |
185 | not be on perl5-porters at any given time, and that a patch is not |
186 | official unless it has been integrated into the author's copy of the |
187 | module. To aid with this, and with points #1, #2, and #3 above, contact |
188 | information for the authors of all contributed modules should be kept with |
189 | the Perl distribution. |
190 | |
191 | Finally, the Perl community as a whole recognizes that respect for |
192 | ownership of code, respect for artistic control, proper credit, and active |
193 | effort to prevent unintentional code skew or communication gaps is vital |
194 | to the health of the community and Perl itself. Members of a community |
195 | should not normally have to resort to rules and laws to deal with each |
196 | other, and this document, although it contains rules so as to be clear, is |
197 | about an attitude and general approach. The first step in any dispute |
198 | should be open communication, respect for opposing views, and an attempt |
199 | at a compromise. In nearly every circumstance nothing more will be |
200 | necessary, and certainly no more drastic measure should be used until |
201 | every avenue of communication and discussion has failed. |
3c78fafa |
202 | |
48cb5b3a |
203 | =head1 CREDITS |
204 | |
76caf4b8 |
205 | Social Contract about Contributed Modules originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters. |
3c78fafa |
206 | |