-
Notifications
You must be signed in to change notification settings - Fork 60
Expand file tree
/
Copy pathcoding_guide.html
More file actions
481 lines (460 loc) · 30.2 KB
/
coding_guide.html
File metadata and controls
481 lines (460 loc) · 30.2 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Pull request guidelines — Matplotlib 3.3.4 documentation</title>
<link rel="stylesheet" href="../_static/mpl.css?v3.3.4" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<link rel="stylesheet" type="text/css" href="../_static/graphviz.css" />
<link rel="stylesheet" type="text/css" href="../_static/copybutton.css" />
<link rel="stylesheet" type="text/css" href="../_static/gallery.css" />
<link rel="stylesheet" type="text/css" href="../_static/gallery-binder.css" />
<link rel="stylesheet" type="text/css" href="../_static/gallery-dataframe.css" />
<link rel="stylesheet" type="text/css" href="../_static/gallery-rendered-html.css" />
<script id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
<script src="../_static/jquery.js"></script>
<script src="../_static/underscore.js"></script>
<script src="../_static/doctools.js"></script>
<script src="../_static/language_data.js"></script>
<script src="../_static/clipboard.min.js"></script>
<script src="../_static/copybutton.js"></script>
<script async="async" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.7/latest.js?config=TeX-AMS-MML_HTMLorMML"></script>
<link rel="search" type="application/opensearchdescription+xml"
title="Search within Matplotlib 3.3.4 documentation"
href="../_static/opensearch.xml"/>
<link rel="shortcut icon" href="../_static/favicon.ico"/>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="Release Guide" href="release_guide.html" />
<link rel="prev" title="Two and three dots in difference specs" href="gitwash/dot2_dot3.html" />
<link rel="top" title="Matplotlib 3.3.4 documentation" href="#" />
<link rel="canonical" href="https://matplotlib.org/stable/devel/coding_guide.html" />
<link rel="stylesheet" href="../_static/custom.css" type="text/css" />
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
<script data-domain="matplotlib.org" defer="defer" src="https://views.scientific-python.org/js/script.js"></script>
</head><body>
<div id="unreleased-message"> You are reading an old version of the documentation (v3.3.4). For the latest version see <a href="https://matplotlib.org/stable/devel/coding_guide.html">https://matplotlib.org/stable/devel/coding_guide.html</a></div>
<!--
<div id="annc-banner">
</div>
-->
<div style="background-color: white; text-align: left; padding: 10px 10px 15px 15px; position: relative;">
<a href="../index.html">
<div style="float: left; position: absolute; width: 496px; bottom: 0; padding-bottom: 24px"><span style="float: right; color: #789; background: white">Version 3.3.4</span></div>
<img src="../_static/logo2_compressed.svg" height="125px" border="0" alt="matplotlib"/></a>
<!-- The "Fork me on github" ribbon -->
<div id="forkongithub"><a href="https://github.com/matplotlib/matplotlib">Fork me on GitHub</a></div>
</div>
<nav class="main-nav">
<ul>
<li><a href="../users/installing.html">Installation</a></li>
<li><a href="../contents.html">Documentation</a></li>
<li><a href="../gallery/index.html">Examples</a></li>
<li><a href="../tutorials/index.html">Tutorials</a></li>
<li><a href="index.html">Contributing</a></li>
<li class="nav-right">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" placeholder="Search"/>
</form>
</li>
</ul>
</nav>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="../genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="../py-modindex.html" title="Python Module Index"
>modules</a> |</li>
<li class="right" >
<a href="release_guide.html" title="Release Guide"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="gitwash/dot2_dot3.html" title="Two and three dots in difference specs"
accesskey="P">previous</a> |</li>
<li><a href="../index.html">home</a>| </li>
<li><a href="../contents.html">contents</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">The Matplotlib Developers' Guide</a> »</li>
<li class="nav-item nav-item-this"><a href="">Pull request guidelines</a></li>
</ul>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Pull request guidelines</a><ul>
<li><a class="reference internal" href="#summary-for-pr-authors">Summary for PR authors</a></li>
<li><a class="reference internal" href="#summary-for-pr-reviewers">Summary for PR reviewers</a></li>
<li><a class="reference internal" href="#detailed-guidelines">Detailed Guidelines</a><ul>
<li><a class="reference internal" href="#documentation">Documentation</a></li>
<li><a class="reference internal" href="#labels">Labels</a></li>
<li><a class="reference internal" href="#milestones">Milestones</a></li>
<li><a class="reference internal" href="#merging">Merging</a></li>
<li><a class="reference internal" href="#automated-tests">Automated tests</a></li>
<li><a class="reference internal" href="#number-of-commits-and-squashing">Number of commits and squashing</a></li>
</ul>
</li>
<li><a class="reference internal" href="#branches-and-backports">Branches and Backports</a><ul>
<li><a class="reference internal" href="#current-branches">Current branches</a></li>
<li><a class="reference internal" href="#branch-selection-for-pull-requests">Branch selection for pull requests</a></li>
<li><a class="reference internal" href="#backport-strategy">Backport strategy</a></li>
<li><a class="reference internal" href="#automated-backports">Automated backports</a></li>
<li><a class="reference internal" href="#manual-backports">Manual backports</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="../contents.html">Documentation overview</a><ul>
<li><a href="index.html">The Matplotlib Developers' Guide</a><ul>
<li>Previous: <a href="gitwash/dot2_dot3.html" title="previous chapter">Two and three dots in difference specs</a></li>
<li>Next: <a href="release_guide.html" title="next chapter">Release Guide</a></li>
</ul></li>
</ul></li>
</ul>
</div>
<div id="sidebar-pagesource" role="note" aria-label="source link"
style="margin-top: 1.5em; padding-top: 0.1em; border-top: 1px solid #86989b">
<a href="../_sources/devel/coding_guide.rst.txt"
style="color: #c0c0c0" rel="nofollow">Show Page Source</a>
</div>
</div>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<style>
.checklist { list-style: none; padding: 0; margin: 0; }
.checklist li { margin-left: 24px; padding-left: 23px; margin-right: 6px; }
.checklist li:before { content: "\2610\2001"; margin-left: -24px; }
.checklist li p {display: inline; }
</style><div class="section" id="pull-request-guidelines">
<h1>Pull request guidelines<a class="headerlink" href="#pull-request-guidelines" title="Permalink to this headline">¶</a></h1>
<p>Pull requests (PRs) are the mechanism for contributing to Matplotlibs code and
documentation.</p>
<div class="section" id="summary-for-pr-authors">
<h2>Summary for PR authors<a class="headerlink" href="#summary-for-pr-authors" title="Permalink to this headline">¶</a></h2>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<ul class="last simple">
<li>We value contributions from people with all levels of experience. In
particular if this is your first PR not everything has to be perfect.
We'll guide you through the PR process.</li>
<li>Nevertheless, try to follow the guidelines below as well as you can to
help make the PR process quick and smooth.</li>
<li>Be patient with reviewers. We try our best to respond quickly, but we
have limited bandwidth. If there is no feedback within a couple of days,
please ping us by posting a comment to your PR.</li>
</ul>
</div>
<p>When making a PR, pay attention to:</p>
<ul class="checklist">
<li><p class="first"><a class="reference internal" href="#pr-branch-selection"><span class="std std-ref">Target the master branch</span></a>.</p>
</li>
<li><p class="first">Adhere to the <a class="reference internal" href="contributing.html#coding-guidelines"><span class="std std-ref">Coding guidelines</span></a>.</p>
</li>
<li><p class="first">Update the <a class="reference internal" href="#pr-documentation"><span class="std std-ref">documentation</span></a> if necessary.</p>
</li>
<li><p class="first">Aim at making the PR as "ready-to-go" as you can. This helps to speed up
the review process.</p>
</li>
<li><p class="first">It is ok to open incomplete or work-in-progress PRs if you need help or
feedback from the developers. You may mark these as
<a class="reference external" href="https://help.github.com/en/articles/about-pull-requests#draft-pull-requests">draft pull requests</a>
on GitHub.</p>
</li>
<li><p class="first">When updating your PR, instead of adding new commits to fix something, please
consider amending your initial commit(s) to keep the history clean.
You can achieve this using:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">commit</span> <span class="o">--</span><span class="n">amend</span> <span class="o">--</span><span class="n">no</span><span class="o">-</span><span class="n">edit</span>
<span class="n">git</span> <span class="n">push</span> <span class="p">[</span><span class="n">your</span><span class="o">-</span><span class="n">remote</span><span class="o">-</span><span class="n">repo</span><span class="p">]</span> <span class="p">[</span><span class="n">your</span><span class="o">-</span><span class="n">branch</span><span class="p">]</span> <span class="o">--</span><span class="n">force</span><span class="o">-</span><span class="k">with</span><span class="o">-</span><span class="n">lease</span>
</pre></div>
</div>
</li>
</ul>
<p>See also <a class="reference internal" href="contributing.html#contributing"><span class="std std-ref">Contributing</span></a> for how to make a PR.</p>
</div>
<div class="section" id="summary-for-pr-reviewers">
<h2>Summary for PR reviewers<a class="headerlink" href="#summary-for-pr-reviewers" title="Permalink to this headline">¶</a></h2>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<ul class="last simple">
<li>If you have commit rights, then you are trusted to use them.
<strong>Please help review and merge PRs!</strong></li>
<li>Be patient and <a class="reference external" href="https://youtu.be/tzFWz5fiVKU?t=49m30s">kind</a> with
contributors.</li>
</ul>
</div>
<p>Content topics:</p>
<ul class="checklist simple">
<li>Is the feature / bugfix reasonable?</li>
<li>Does the PR conform with the <a class="reference internal" href="contributing.html#coding-guidelines"><span class="std std-ref">Coding guidelines</span></a>?</li>
<li>Is the <a class="reference internal" href="#pr-documentation"><span class="std std-ref">documentation</span></a> (docstrings, examples,
what's new, API changes) updated?</li>
</ul>
<p>Organizational topics:</p>
<ul class="checklist simple">
<li>Make sure all <a class="reference internal" href="#pr-automated-tests"><span class="std std-ref">automated tests</span></a> pass.</li>
<li>The PR should <a class="reference internal" href="#pr-branch-selection"><span class="std std-ref">target the master branch</span></a>.</li>
<li>Tag with descriptive <a class="reference internal" href="#pr-labels"><span class="std std-ref">labels</span></a>.</li>
<li>Set the <a class="reference internal" href="#pr-milestones"><span class="std std-ref">milestone</span></a>.</li>
<li>Keep an eye on the <a class="reference internal" href="#pr-squashing"><span class="std std-ref">number of commits</span></a>.</li>
<li>Approve if all of the above topics handled.</li>
<li><a class="reference internal" href="#pr-merging"><span class="std std-ref">Merge</span></a> if a sufficient number of approvals is reached.</li>
</ul>
</div>
<div class="section" id="detailed-guidelines">
<span id="pr-guidelines-details"></span><h2>Detailed Guidelines<a class="headerlink" href="#detailed-guidelines" title="Permalink to this headline">¶</a></h2>
<div class="section" id="documentation">
<span id="pr-documentation"></span><h3>Documentation<a class="headerlink" href="#documentation" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li>Every new feature should be documented. If it's a new module, don't
forget to add a new rst file to the API docs.</li>
<li>Each high-level plotting function should have a small example in
the <code class="docutils literal notranslate"><span class="pre">Examples</span></code> section of the docstring. This should be as simple as
possible to demonstrate the method. More complex examples should go into
a dedicated example file in the <code class="file docutils literal notranslate"><span class="pre">examples</span></code> directory, which will be
rendered to the examples gallery in the documentation.</li>
<li>Build the docs and make sure all formatting warnings are addressed.</li>
<li>See <a class="reference internal" href="documenting_mpl.html#documenting-matplotlib"><span class="std std-ref">Writing documentation</span></a> for our documentation style guide.</li>
<li>If your change is a major new feature, add an entry to
<code class="file docutils literal notranslate"><span class="pre">doc/users/whats_new.rst</span></code>.</li>
<li>If you change the API in a backward-incompatible way, please
document it in the relevant file in most recent
<code class="file docutils literal notranslate"><span class="pre">doc/api/api_changes_X.Y</span></code>.</li>
</ul>
</div>
<div class="section" id="labels">
<span id="pr-labels"></span><h3>Labels<a class="headerlink" href="#labels" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li>If you have the rights to set labels, tag the PR with descriptive labels.
See the <a class="reference external" href="https://github.com/matplotlib/matplotlib/labels">list of labels</a>.</li>
</ul>
</div>
<div class="section" id="milestones">
<span id="pr-milestones"></span><h3>Milestones<a class="headerlink" href="#milestones" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">Set the milestone according to these rules:</p>
<ul class="simple">
<li><em>New features and API changes</em> are milestoned for the next minor release
<code class="docutils literal notranslate"><span class="pre">v3.X.0</span></code>.</li>
<li><em>Bugfixes and docstring changes</em> are milestoned for the next patch
release <code class="docutils literal notranslate"><span class="pre">v3.X.Y</span></code></li>
<li><em>Documentation changes</em> (all .rst files and examples) are milestoned
<code class="docutils literal notranslate"><span class="pre">v3.X-doc</span></code></li>
</ul>
<p>If multiple rules apply, choose the first matching from the above list.</p>
<p>Setting a milestone does not imply or guarantee that a PR will be merged for that
release, but if it were to be merged what release it would be in.</p>
<p>All of these PRs should target the master branch. The milestone tag triggers
an <a class="reference internal" href="#automated-backports"><span class="std std-ref">automatic backport</span></a> for milestones which have
a corresponding branch.</p>
</li>
</ul>
</div>
<div class="section" id="merging">
<span id="pr-merging"></span><h3>Merging<a class="headerlink" href="#merging" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">Documentation and examples may be merged by the first reviewer. Use
the threshold "is this better than it was?" as the review criteria.</p>
</li>
<li><p class="first">For code changes (anything in <code class="docutils literal notranslate"><span class="pre">src</span></code> or <code class="docutils literal notranslate"><span class="pre">lib</span></code>) at least two
core developers (those with commit rights) should review all pull
requests. If you are the first to review a PR and approve of the
changes use the GitHub <a class="reference external" href="https://help.github.com/articles/reviewing-changes-in-pull-requests/">'approve review'</a>
tool to mark it as such. If you are a subsequent reviewer please
approve the review and if you think no more review is needed, merge
the PR.</p>
<p>Ensure that all API changes are documented in the relevant file in
the most recent <code class="file docutils literal notranslate"><span class="pre">doc/api/api_changes_X.Y</span></code> and significant new features
have an entry in <code class="file docutils literal notranslate"><span class="pre">doc/user/whats_new</span></code>.</p>
<ul>
<li><p class="first">If a PR already has a positive review, a core developer (e.g. the first
reviewer, but not necessarily) may champion that PR for merging. In order
to do so, they should ping all core devs both on GitHub and on the dev
mailing list, and label the PR with the "Merge with single review?" label.
Other core devs can then either review the PR and merge or reject it, or
simply request that it gets a second review before being merged. If no one
asks for such a second review within a week, the PR can then be merged on
the basis of that single review.</p>
<p>A core dev should only champion one PR at a time and we should try to keep
the flow of championed PRs reasonable.</p>
</li>
</ul>
</li>
<li><p class="first">Do not self merge, except for 'small' patches to un-break the CI or
when another reviewer explicitly allows it (ex, "Approve modulo CI
passing, may self merge when green").</p>
</li>
</ul>
</div>
<div class="section" id="automated-tests">
<span id="pr-automated-tests"></span><h3>Automated tests<a class="headerlink" href="#automated-tests" title="Permalink to this headline">¶</a></h3>
<p>Whenever a pull request is created or updated, various automated test tools
will run on all supported platforms and versions of Python.</p>
<ul class="simple">
<li>Make sure the Linting, Travis, AppVeyor, CircleCI, and Azure pipelines are
passing before merging (All checks are listed at the bottom of the GitHub
page of your pull request). Here are some tips for finding the cause of the
test failure:<ul>
<li>If <em>Linting</em> fails, you have a code style issue, which will be listed
as annotations on the pull request's diff.</li>
<li>If a Travis or AppVeyor run fails, search the log for <code class="docutils literal notranslate"><span class="pre">FAILURES</span></code>. The
subsequent section will contain information on the failed tests.</li>
<li>If CircleCI fails, likely you have some reStructuredText style issue in
the docs. Search the CircleCI log for <code class="docutils literal notranslate"><span class="pre">WARNING</span></code>.</li>
<li>If Azure pipelines fail with an image comparison error, you can find the
images as <em>artifacts</em> of the Azure job:<ul>
<li>Click <em>Details</em> on the check on the GitHub PR page.</li>
<li>Click <em>View more details on Azure Pipelines</em> to go to Azure.</li>
<li>On the overview page <em>artifacts</em> are listed in the section <em>Related</em>.</li>
</ul>
</li>
</ul>
</li>
<li>Codecov and LGTM are currently for information only. Their failure is not
necessarily a blocker.</li>
<li><a class="reference external" href="https://tox.readthedocs.io/">tox</a> is not used in the automated testing. It is supported for testing
locally.</li>
</ul>
</div>
<div class="section" id="number-of-commits-and-squashing">
<span id="pr-squashing"></span><h3>Number of commits and squashing<a class="headerlink" href="#number-of-commits-and-squashing" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li>Squashing is case-by-case. The balance is between burden on the
contributor, keeping a relatively clean history, and keeping a
history usable for bisecting. The only time we are really strict
about it is to eliminate binary files (ex multiple test image
re-generations) and to remove upstream merges.</li>
<li>Do not let perfect be the enemy of the good, particularly for
documentation or example PRs. If you find yourself making many
small suggestions, either open a PR against the original branch,
push changes to the contributor branch, or merge the PR and then
open a new PR against upstream.</li>
<li>If you push to a contributor branch leave a comment explaining what
you did, ex "I took the liberty of pushing a small clean-up PR to
your branch, thanks for your work.". If you are going to make
substantial changes to the code or intent of the PR please check
with the contributor first.</li>
</ul>
</div>
</div>
<div class="section" id="branches-and-backports">
<span id="id1"></span><h2>Branches and Backports<a class="headerlink" href="#branches-and-backports" title="Permalink to this headline">¶</a></h2>
<div class="section" id="current-branches">
<h3>Current branches<a class="headerlink" href="#current-branches" title="Permalink to this headline">¶</a></h3>
<p>The current active branches are</p>
<dl class="docutils">
<dt><em>master</em></dt><dd>The current development version. Future minor releases (<em>v3.N.0</em>) will be
branched from this. Supports Python 3.6+.</dd>
<dt><em>v3.N.x</em></dt><dd>Maintenance branch for Matplotlib 3.N. Future patch releases will be
branched from this. Supports Python 3.6+.</dd>
<dt><em>v3.N.M-doc</em></dt><dd>Documentation for the current release. On a patch release, this will be
replaced by a properly named branch for the new release.</dd>
<dt><em>v2.2.x</em></dt><dd>Maintenance branch for Matplotlib 2.2 LTS. Supports Python 2.7, 3.4+.</dd>
<dt><em>v2.2.N-doc</em></dt><dd>Documentation for the current release. On a patch release, this will be
replaced by a properly named branch for the new release.</dd>
</dl>
</div>
<div class="section" id="branch-selection-for-pull-requests">
<span id="pr-branch-selection"></span><h3>Branch selection for pull requests<a class="headerlink" href="#branch-selection-for-pull-requests" title="Permalink to this headline">¶</a></h3>
<p>Generally, all pull requests should target the master branch.</p>
<p>Other branches are fed through <a class="reference internal" href="#automated-backports"><span class="std std-ref">automatic</span></a> or
<a class="reference internal" href="#manual-backports"><span class="std std-ref">manual</span></a>. Directly
targeting other branches is only rarely necessary for special maintenance
work.</p>
</div>
<div class="section" id="backport-strategy">
<h3>Backport strategy<a class="headerlink" href="#backport-strategy" title="Permalink to this headline">¶</a></h3>
<p>We will always backport to the patch release branch (<em>v3.N.x</em>):</p>
<ul class="simple">
<li>critical bug fixes (segfault, failure to import, things that the
user can not work around)</li>
<li>fixes for regressions against the last two releases.</li>
</ul>
<p>Everything else (regressions against older releases, bugs/api
inconsistencies the user can work around in their code) are on a
case-by-case basis, should be low-risk, and need someone to advocate
for and shepherd through the backport.</p>
<p>The only changes to be backported to the documentation branch (<em>v3.N.M-doc</em>)
are changes to <code class="file docutils literal notranslate"><span class="pre">doc</span></code>, <code class="file docutils literal notranslate"><span class="pre">examples</span></code>, or <code class="file docutils literal notranslate"><span class="pre">tutorials</span></code>.
Any changes to <code class="file docutils literal notranslate"><span class="pre">lib</span></code> or <code class="file docutils literal notranslate"><span class="pre">src</span></code> including docstring-only changes
should not be backported to this branch.</p>
</div>
<div class="section" id="automated-backports">
<span id="id2"></span><h3>Automated backports<a class="headerlink" href="#automated-backports" title="Permalink to this headline">¶</a></h3>
<p>We use meeseeksdev bot to automatically backport merges to the correct
maintenance branch base on the milestone. To work properly the
milestone must be set before merging. If you have commit rights, the
bot can also be manually triggered after a merge by leaving a message
<code class="docutils literal notranslate"><span class="pre">@meeseeksdev</span> <span class="pre">backport</span> <span class="pre">to</span> <span class="pre">BRANCH</span></code> on the PR. If there are conflicts
meeseekdevs will inform you that the backport needs to be done
manually.</p>
<p>The target branch is configured by putting <code class="docutils literal notranslate"><span class="pre">on-merge:</span> <span class="pre">backport</span> <span class="pre">to</span>
<span class="pre">TARGETBRANCH</span></code> in the milestone description on it's own line.</p>
<p>If the bot is not working as expected, please report issues to
<a class="reference external" href="https://github.com/MeeseeksBox/MeeseeksDev">Meeseeksdev</a>.</p>
</div>
<div class="section" id="manual-backports">
<span id="id3"></span><h3>Manual backports<a class="headerlink" href="#manual-backports" title="Permalink to this headline">¶</a></h3>
<p>When doing backports please copy the form used by meeseekdev,
<code class="docutils literal notranslate"><span class="pre">Backport</span> <span class="pre">PR</span> <span class="pre">#XXXX:</span> <span class="pre">TITLE</span> <span class="pre">OF</span> <span class="pre">PR</span></code>. If you need to manually resolve
conflicts make note of them and how you resolved them in the commit
message.</p>
<p>We do a backport from master to v2.2.x assuming:</p>
<ul class="simple">
<li><code class="docutils literal notranslate"><span class="pre">matplotlib</span></code> is a read-only remote branch of the matplotlib/matplotlib repo</li>
</ul>
<p>The <code class="docutils literal notranslate"><span class="pre">TARGET_SHA</span></code> is the hash of the merge commit you would like to
backport. This can be read off of the GitHub PR page (in the UI with
the merge notification) or through the git CLI tools.</p>
<p>Assuming that you already have a local branch <code class="docutils literal notranslate"><span class="pre">v2.2.x</span></code> (if not, then
<code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">checkout</span> <span class="pre">-b</span> <span class="pre">v2.2.x</span></code>), and that your remote pointing to
<code class="docutils literal notranslate"><span class="pre">https://github.com/matplotlib/matplotlib</span></code> is called <code class="docutils literal notranslate"><span class="pre">upstream</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">fetch</span> <span class="n">upstream</span>
<span class="n">git</span> <span class="n">checkout</span> <span class="n">v2</span><span class="o">.</span><span class="mf">2.</span><span class="n">x</span> <span class="c1"># or include -b if you don't already have this.</span>
<span class="n">git</span> <span class="n">reset</span> <span class="o">--</span><span class="n">hard</span> <span class="n">upstream</span><span class="o">/</span><span class="n">v2</span><span class="o">.</span><span class="mf">2.</span><span class="n">x</span>
<span class="n">git</span> <span class="n">cherry</span><span class="o">-</span><span class="n">pick</span> <span class="o">-</span><span class="n">m</span> <span class="mi">1</span> <span class="n">TARGET_SHA</span>
<span class="c1"># resolve conflicts and commit if required</span>
</pre></div>
</div>
<p>Files with conflicts can be listed by <code class="docutils literal notranslate"><span class="pre">git</span> <span class="pre">status</span></code>,
and will have to be fixed by hand (search on <code class="docutils literal notranslate"><span class="pre">>>>>></span></code>). Once
the conflict is resolved, you will have to re-add the file(s) to the branch
and then continue the cherry pick:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">add</span> <span class="n">lib</span><span class="o">/</span><span class="n">matplotlib</span><span class="o">/</span><span class="n">conflicted_file</span><span class="o">.</span><span class="n">py</span>
<span class="n">git</span> <span class="n">add</span> <span class="n">lib</span><span class="o">/</span><span class="n">matplotlib</span><span class="o">/</span><span class="n">conflicted_file2</span><span class="o">.</span><span class="n">py</span>
<span class="n">git</span> <span class="n">cherry</span><span class="o">-</span><span class="n">pick</span> <span class="o">--</span><span class="k">continue</span>
</pre></div>
</div>
<p>Use your discretion to push directly to upstream or to open a PR; be
sure to push or PR against the <code class="docutils literal notranslate"><span class="pre">v2.2.x</span></code> upstream branch, not <code class="docutils literal notranslate"><span class="pre">master</span></code>!</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<footer>
<div class="footer">
© Copyright 2002 - 2012 John Hunter, Darren Dale, Eric Firing, Michael Droettboom and the Matplotlib development team; 2012 - 2021 The Matplotlib development team.
<br />
Last updated on Jan 28, 2021.
Created using
<a href="http://sphinx-doc.org/">Sphinx</a> 3.1.1.
Doc version v3.3.4.
</div>
</footer>
</body>
</html>