pod/perlpolicy.pod

   1 =head1 NAME
   2
   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
  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.)
  85
  86 =head1 CONTRIBUTED MODULES
  87
  88
  89 =head2 A Social Contract about Artistic Control
  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.
 108 From time to time, a script, module, or set of modules (hereafter referred
 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
 124 =over
 125
 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.
 132
 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
 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
 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
 169 should B<always> if at all possible be done only after direct input
 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.
 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.
 202
 203 =head1 CREDITS
 204
 205 Social Contract about Contributed Modules originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters.
 206