501 lines
31 KiB
HTML
501 lines
31 KiB
HTML
|
||
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<meta name="color-scheme" content="light dark">
|
||
<title>PEP 595 – Improving bugs.python.org | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-0595/">
|
||
<link rel="stylesheet" href="../_static/style.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/mq.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light">
|
||
<link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark">
|
||
<link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss">
|
||
<meta property="og:title" content='PEP 595 – Improving bugs.python.org | peps.python.org'>
|
||
<meta property="og:description" content="This PEP proposes a list of improvements to make bugs.python.org more usable for contributors and core developers. This PEP also discusses why remaining on Roundup should be preferred over switching to GitHub Issues, as proposed by PEP 581.">
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-0595/">
|
||
<meta property="og:site_name" content="Python Enhancement Proposals (PEPs)">
|
||
<meta property="og:image" content="https://peps.python.org/_static/og-image.png">
|
||
<meta property="og:image:alt" content="Python PEPs">
|
||
<meta property="og:image:width" content="200">
|
||
<meta property="og:image:height" content="200">
|
||
<meta name="description" content="This PEP proposes a list of improvements to make bugs.python.org more usable for contributors and core developers. This PEP also discusses why remaining on Roundup should be preferred over switching to GitHub Issues, as proposed by PEP 581.">
|
||
<meta name="theme-color" content="#3776ab">
|
||
</head>
|
||
<body>
|
||
|
||
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
|
||
<symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Following system colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="9"></circle>
|
||
<path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected dark colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
|
||
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected light colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="5"></circle>
|
||
<line x1="12" y1="1" x2="12" y2="3"></line>
|
||
<line x1="12" y1="21" x2="12" y2="23"></line>
|
||
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
|
||
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
|
||
<line x1="1" y1="12" x2="3" y2="12"></line>
|
||
<line x1="21" y1="12" x2="23" y2="12"></line>
|
||
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
|
||
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
|
||
</svg>
|
||
</symbol>
|
||
</svg>
|
||
<script>
|
||
|
||
document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto"
|
||
</script>
|
||
<section id="pep-page-section">
|
||
<header>
|
||
<h1>Python Enhancement Proposals</h1>
|
||
<ul class="breadcrumbs">
|
||
<li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li>
|
||
<li><a href="../pep-0000/">PEP Index</a> » </li>
|
||
<li>PEP 595</li>
|
||
</ul>
|
||
<button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())">
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg>
|
||
<span class="visually-hidden">Toggle light / dark / auto colour theme</span>
|
||
</button>
|
||
</header>
|
||
<article>
|
||
<section id="pep-content">
|
||
<h1 class="page-title">PEP 595 – Improving bugs.python.org</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Ezio Melotti <ezio.melotti at gmail.com>, Berker Peksag <berker.peksag at gmail.com></dd>
|
||
<dt class="field-even">BDFL-Delegate<span class="colon">:</span></dt>
|
||
<dd class="field-even">Barry Warsaw <barry at python.org></dd>
|
||
<dt class="field-odd">Status<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Removed from consideration by sponsor or authors">Withdrawn</abbr></dd>
|
||
<dt class="field-even">Type<span class="colon">:</span></dt>
|
||
<dd class="field-even"><abbr title="Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem">Informational</abbr></dd>
|
||
<dt class="field-odd">Created<span class="colon">:</span></dt>
|
||
<dd class="field-odd">12-May-2019</dd>
|
||
</dl>
|
||
<hr class="docutils" />
|
||
<section id="contents">
|
||
<details><summary>Table of Contents</summary><ul class="simple">
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#resolution">Resolution</a></li>
|
||
<li><a class="reference internal" href="#motivation">Motivation</a></li>
|
||
<li><a class="reference internal" href="#roundup-advantages-over-github-issues">Roundup advantages over GitHub Issues</a></li>
|
||
<li><a class="reference internal" href="#improving-roundup">Improving Roundup</a></li>
|
||
<li><a class="reference internal" href="#pep-581-issues">PEP 581 issues</a></li>
|
||
<li><a class="reference internal" href="#migration-considerations">Migration considerations</a></li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
</details></section>
|
||
<section id="abstract">
|
||
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
|
||
<p>This PEP proposes a list of improvements to make bugs.python.org
|
||
more usable for contributors and core developers. This PEP also
|
||
discusses why remaining on Roundup should be preferred over
|
||
switching to GitHub Issues, as proposed by <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a>.</p>
|
||
</section>
|
||
<section id="resolution">
|
||
<h2><a class="toc-backref" href="#resolution" role="doc-backlink">Resolution</a></h2>
|
||
<p>2020-06-25: With the acceptance of <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a>, the move to GitHub for
|
||
issues is proceeding, this PEP is being marked as a withdrawn
|
||
informational PEP.</p>
|
||
</section>
|
||
<section id="motivation">
|
||
<h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2>
|
||
<p>On May 14th, 2019 <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a> has been <a class="reference external" href="https://mail.python.org/pipermail/python-dev/2019-May/157399.html">accepted</a>
|
||
without much public discussion and <a class="reference external" href="https://mail.python.org/pipermail/python-committers/2019-May/006755.html">without a clear consensus</a>.
|
||
The PEP contains factual errors and doesn’t address some of the
|
||
issues that the migration to GitHub Issues might present.</p>
|
||
<p>Given the scope of the migration, the amount of work required,
|
||
and how it will negatively affect the workflow during the
|
||
transition phase, this decision should be re-evaluated.</p>
|
||
</section>
|
||
<section id="roundup-advantages-over-github-issues">
|
||
<h2><a class="toc-backref" href="#roundup-advantages-over-github-issues" role="doc-backlink">Roundup advantages over GitHub Issues</a></h2>
|
||
<p>This section discusses reasons why Roundup should be preferred
|
||
over GitHub Issues and Roundup features that are not available
|
||
on GitHub Issues.</p>
|
||
<ul>
|
||
<li><strong>Roundup is the status quo.</strong> Roundup has been an integral
|
||
part of the CPython workflow for years. It is a stable product
|
||
that has been tested and customized to adapt to our needs as the
|
||
workflow evolved.<p>It is possible to gradually improve it and avoid the disruption
|
||
that a switch to a different system would inevitably bring to
|
||
the workflow.</p>
|
||
</li>
|
||
<li><strong>Open-source and Python powered.</strong> Roundup is an open-source
|
||
project and is written in Python. By using it and supporting
|
||
it, we also support the Python ecosystem. Several features
|
||
developed for bpo have also been ported to upstream Roundup
|
||
over the years.</li>
|
||
<li><strong>Fully customizable.</strong> Roundup can be (and has been) fully
|
||
customized to fit our needs.</li>
|
||
<li><strong>Finer-grained access control.</strong> Roundup allows the creation
|
||
of different roles with different permissions (e.g. create,
|
||
view, edit, etc.) for each individual property, and users can
|
||
have multiple roles.</li>
|
||
<li><strong>Flexible UI.</strong> While Roundup UI might look dated, it is
|
||
convenient and flexible.<p>For example, on the issue page, each field (e.g. title, type,
|
||
versions, status, linked files and PRs, etc.) have appropriate
|
||
UI elements (input boxes, dropdowns, tables, etc.) that are
|
||
easy to set and also provide a convenient way to get info about
|
||
the issue at a glance. The number of fields, their values, and
|
||
the UI element they use is also fully customizable.
|
||
GitHub only provides labels.</p>
|
||
<p>The issue list page presents the issues in a compact and easy
|
||
to read table with separate columns for different fields. For
|
||
comparison, Roundup lists 50 issues in a screen, whereas GitHub
|
||
takes two screens to shows 25 issues.</p>
|
||
</li>
|
||
<li><strong>Advanced search.</strong> Roundup provides an accurate way to search
|
||
and filter by using any combination of issue fields.
|
||
It is also possible to customize the number of results and the
|
||
fields displayed in the table, and the sorting and grouping
|
||
(up to two levels).<p>bpo also provides predefined summaries (e.g. “Created by you”,
|
||
“Assigned to you”, etc.) and allows the creation of custom
|
||
search queries that can be conveniently accessed from the sidebar.</p>
|
||
</li>
|
||
<li><strong>Nosy list autocomplete.</strong> The nosy list has an autocomplete
|
||
feature that suggests maintainers and experts. The suggestions
|
||
are automatically updated when the <a class="reference external" href="https://devguide.python.org/experts/">experts index</a> changes.</li>
|
||
<li><strong>Dependencies and Superseders.</strong> Roundup allows to specify
|
||
dependencies that must be addressed before the current issues
|
||
can be closed and a superseder issue to easily mark duplicates
|
||
(for example, <a class="reference external" href="https://bugs.python.org/issue12078">bpo-12078</a>).
|
||
The list of dependencies can also be used to create
|
||
meta-issues that references several other sub-issues
|
||
(for example, <a class="reference external" href="https://bugs.python.org/issue26865">bpo-26865</a>).</li>
|
||
</ul>
|
||
</section>
|
||
<section id="improving-roundup">
|
||
<h2><a class="toc-backref" href="#improving-roundup" role="doc-backlink">Improving Roundup</a></h2>
|
||
<p>This section lists some of the issues mentioned by <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a>
|
||
and other desired features and discusses how they can be implemented
|
||
by improving Roundup and/or our instance.</p>
|
||
<ul>
|
||
<li><strong>REST API support.</strong> A REST API will make integration with other
|
||
services and the development of new tools and applications easier.<p>Upstream Roundup now supports a REST API. Updating the tracker will
|
||
make the REST API available.</p>
|
||
</li>
|
||
<li><strong>GitHub login support.</strong> This will allow users to login
|
||
to bugs.python.org (bpo) without having to create a new account.
|
||
It will also solve issues with confirmation emails being marked
|
||
as spam, and provide two-factor authentication.<p>A patch to add this functionality is <a class="reference external" href="https://github.com/python/bugs.python.org/issues/7">already available</a>
|
||
and is being integrated at the time of writing.</p>
|
||
</li>
|
||
<li><strong>Markdown support and message preview and editing.</strong> This feature
|
||
will allow the use of Markdown in messages and the ability to
|
||
preview the message before the submission and edit it afterward.<p>This can be done, but it will take some work. Possible solutions
|
||
have been proposed on the <a class="reference external" href="https://sourceforge.net/p/roundup/mailman/message/36667828/">roundup-devel mailing list</a>.</p>
|
||
</li>
|
||
<li><strong>“Remove me from nosy list” button.</strong> Add a button on issue pages
|
||
to remove self from the nosy list.<p>This feature will be added during GSoC 2019.</p>
|
||
</li>
|
||
<li><strong>Mobile friendly theme.</strong> Current theme of bugs.python.org looks
|
||
dated and it doesn’t work well with mobile browsers.<p>A mobile-friendly theme that is more modern but still familiar
|
||
will be added.</p>
|
||
</li>
|
||
<li><strong>Move reply box close to the last message.</strong> The reply box is
|
||
located at the top of the page, whereas the last message is at the
|
||
bottom.<p>The reply box can be moved or duplicated after the last message.</p>
|
||
</li>
|
||
<li><strong>Real-time updates.</strong> When another users submits changes to an
|
||
issue, they should show up in real time.<p>This can be accomplished by using the REST API.</p>
|
||
</li>
|
||
<li><strong>Add PR link to BPO emails.</strong> Currently bpo emails don’t include
|
||
links to the corresponding PRs.<p>A <a class="reference external" href="https://mail.python.org/pipermail/tracker-discuss/2018-June/004547.html">patch</a>
|
||
is available to change the content of the bpo emails from:</p>
|
||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>components: +Tkinter
|
||
versions: +Python 3.4
|
||
pull_requests: +42
|
||
</pre></div>
|
||
</div>
|
||
<p>to:</p>
|
||
<div class="highlight-text notranslate"><div class="highlight"><pre><span></span>components: +Tkinter
|
||
versions: +Python 3.4
|
||
pull_request: https://github.com/python/cpython/pull/341
|
||
</pre></div>
|
||
</div>
|
||
</li>
|
||
<li><strong>Python 3 support.</strong> Using Python 3 will make maintenance easier.<p>Upstream Roundup now supports Python 3. Updating the tracker will
|
||
allow us to switch to Python 3. The instances will need to be
|
||
updated as well.</p>
|
||
</li>
|
||
<li><strong>Use upstream Roundup.</strong> We currently use a fork of Roundup with
|
||
a few modifications, most notably the GitHub integration. If this
|
||
is ported upstream, we can start using upstream Roundup without
|
||
having to maintain our fork.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="pep-581-issues">
|
||
<h2><a class="toc-backref" href="#pep-581-issues" role="doc-backlink">PEP 581 issues</a></h2>
|
||
<p>This section addresses some errors and inaccuracies found in <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a>.</p>
|
||
<p>The “Why GitHub?” section of <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a> lists features currently
|
||
available on GitHub Issues but not on Roundup. Some of this features
|
||
are currently supported:</p>
|
||
<ul>
|
||
<li>“Ability to reply to issue and pull request conversations via email.”<ul class="simple">
|
||
<li>Being able to reply by email has been one of the core features of
|
||
Roundup since the beginning. It is also possible to create new
|
||
issues or close existing ones, set or modify fields, and add
|
||
attachments.</li>
|
||
</ul>
|
||
</li>
|
||
<li>“Email notifications containing metadata, integrated with Gmail,
|
||
allowing systematic filtering of emails.”<ul class="simple">
|
||
<li>Emails sent by Roundup contains metadata that can be used for
|
||
filtering.</li>
|
||
</ul>
|
||
</li>
|
||
<li>“Additional privacy, such as offering the user a choice to hide an
|
||
email address, while still allowing communication with the user
|
||
through @-mentions.”<ul class="simple">
|
||
<li>Email addresses are hidden by default to users that are not
|
||
registered. Registered users can see other users’ addresses
|
||
because we configured the tracker to show them. It can easily
|
||
be changed if desired. Users can still be added to the nosy
|
||
list by using their username even if their address is hidden.</li>
|
||
</ul>
|
||
</li>
|
||
<li>“Ability to automatically close issues when a PR has been merged.”<ul class="simple">
|
||
<li>The GitHub integration of Roundup automatically closes issues
|
||
when a commit that contains “fixes issue <id>” is merged.
|
||
(Alternative spellings such as “closes” or “bug” are also supported.)
|
||
See <a class="reference external" href="https://bugs.python.org/issue36951#msg342882">this message</a>
|
||
for a recent example of this feature.</li>
|
||
</ul>
|
||
</li>
|
||
<li>“Support for permalinks, allowing easy quoting and copying &
|
||
pasting of source code.”<ul class="simple">
|
||
<li>Roundup has permalinks for issues, messages, attachments, etc.
|
||
In addition, Roundup allows to easily rewrite broken URLs in
|
||
messages (e.g. if the code hosting changes).</li>
|
||
</ul>
|
||
</li>
|
||
<li>“Core developers, volunteers, and the PSF don’t have to maintain the
|
||
issue infrastructure/site, giving us more time and resources to focus
|
||
on the development of Python.”<ul>
|
||
<li>While this is partially true, additional resources are required to
|
||
write and maintain bots.<p>In some cases, bots are required to workaround GitHub’s lack of
|
||
features rather than expanding. <a class="reference external" href="https://github.com/berkerpeksag/cpython-emailer-webhook">This webhook</a>
|
||
was written specifically to workaround GitHub’s email integration.</p>
|
||
<p>Updating our bots to stay up-to-date with changes in the GitHub API
|
||
has also maintenance cost. <a class="reference external" href="https://github.com/python/bedevere/pull/163">This recent incident caused by GitHub</a>
|
||
took two days to be fixed.</p>
|
||
<p>In addition, we will still need to maintain Roundup for bpo (even
|
||
if it becomes read-only) and for the other trackers
|
||
we currently host/maintain (<a class="reference external" href="https://bugs.jython.org/">Jython</a>
|
||
and <a class="reference external" href="https://issues.roundup-tracker.org/">Roundup</a>).</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<p>The “Issues with Roundup / bpo” section of <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a> lists some issues
|
||
that have already been fixed:</p>
|
||
<ul>
|
||
<li>“The upstream Roundup code is in Mercurial. Without any CI available,
|
||
it puts heavy burden on the few existing maintainers in terms of
|
||
reviewing, testing, and applying patches.”<ul class="simple">
|
||
<li>While Roundup uses Mercurial by default, there is a <a class="reference external" href="https://github.com/roundup-tracker/roundup">git clone
|
||
available on GitHub</a>.
|
||
Roundup also has CI available on <a class="reference external" href="https://github.com/roundup-tracker/roundup">Travis CI</a> and <a class="reference external" href="https://codecov.io/gh/roundup-tracker/roundup/commits">Codecov</a>.</li>
|
||
</ul>
|
||
</li>
|
||
<li>“There is no REST API available. There is an open issue in Roundup for
|
||
adding REST API. Last activity was in 2016.”<ul class="simple">
|
||
<li>The REST API has been integrated and it’s now available in Roundup.</li>
|
||
</ul>
|
||
</li>
|
||
<li>“Users email addresses are exposed. There is no option to mask it.”<ul>
|
||
<li>Exposing addresses to registered and logged in users was a decision
|
||
taken when our instance was set up.<p>This has now been changed to make the email addresses hidden for
|
||
regular users too (Developers and Coordinators can still see them).
|
||
The “Email address” column from the <a class="reference external" href="https://bugs.python.org/user?@sort=username">user listing page</a> has been
|
||
removed too.</p>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li>“It sends a number of unnecessary emails and notifications, and it is
|
||
difficult, if not impossible, to configure.”<ul class="simple">
|
||
<li>This can be configured.</li>
|
||
</ul>
|
||
</li>
|
||
<li>“Creating an account has been a hassle. There have been reports of people
|
||
having trouble creating accounts or logging in.”<ul class="simple">
|
||
<li>The main issue is confirmation emails being marked as spam. Work has
|
||
been done to resolve the issue.</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</section>
|
||
<section id="migration-considerations">
|
||
<h2><a class="toc-backref" href="#migration-considerations" role="doc-backlink">Migration considerations</a></h2>
|
||
<p>This section describes issues with the migrations that might not
|
||
have been addressed by <a class="pep reference internal" href="../pep-0581/" title="PEP 581 – Using GitHub Issues for CPython">PEP 581</a> and <a class="pep reference internal" href="../pep-0588/" title="PEP 588 – GitHub Issues Migration Plan">PEP 588</a>.</p>
|
||
<p><a class="pep reference internal" href="../pep-0588/" title="PEP 588 – GitHub Issues Migration Plan">PEP 588</a> suggests to add a button to migrate issues to GitHub
|
||
only when someone wants to keep working on them. This approach
|
||
has several issues, but there are also other issues that will
|
||
need to be addressed regardless of the approach used:</p>
|
||
<ul>
|
||
<li><strong>Vendor lock-in.</strong> GitHub is proprietary and there is risk
|
||
of vendor lock-in. Their business model might change and they
|
||
could shut down altogether. For example, several projects
|
||
decided to move away from GitHub after Microsoft acquisition.<p>If/when the repository is no longer available on GitHub, we will
|
||
be forced to migrate again and all the links to the issues won’t
|
||
work anymore.</p>
|
||
</li>
|
||
<li><strong>Required bpo updates.</strong> bpo will need to be updated in order
|
||
to add a button that, once pressed, creates a new issue on
|
||
GitHub, copies over all the messages, attachments, and
|
||
creates/adds labels for the existing fields. Permissions will
|
||
also need to be tweaked to make individual issues read-only
|
||
once they are migrated, and to prevent users to create new
|
||
accounts. It might be necessary to set up redirects (see below).</li>
|
||
<li><strong>Two trackers.</strong> If issues are migrated on demand, the issues
|
||
will be split between two trackers. Referencing and searching
|
||
issues will take significant more effort.</li>
|
||
<li><strong>Lossy conversion.</strong> GitHub only mechanism to add custom metadata
|
||
is through labels. bpo uses a number of fields to specify several
|
||
different metadata. Preserving all fields and values will result
|
||
in too many labels. If only some fields and values are preserved
|
||
the others will be lost (unless there is a way to preserve them
|
||
elsewhere).</li>
|
||
<li><strong>Issue IDs preservation.</strong> GitHub doesn’t provide a way to
|
||
set and preserve the ID of migrated issues. Some projects managed
|
||
to preserve the IDs by contacting the GitHub staff and migrating
|
||
the issues <em>en masse</em>. However, this is no longer possible, since
|
||
PRs and issues share the same namespace and PRs already use
|
||
existing bpo issue IDs.</li>
|
||
<li><strong>Internal issue links preservation.</strong> Existing issues might
|
||
contain references to other issues in messages and fields (e.g.
|
||
dependencies or superseder). Since the issue ID will change
|
||
during the migration, these will need to be updated. If the
|
||
issues are migrated on demand, all the existing internal
|
||
references to the migrated issues (on both bpo and GitHub issues)
|
||
will have to be updated.<p>Setting up a redirect for each migrated issue on bpo might
|
||
mitigate the issue, however – if references in migrated messages
|
||
are not updated – it will cause confusion (e.g. if bpo issue
|
||
<code class="docutils literal notranslate"><span class="pre">#1234</span></code> becomes GitHub issue <code class="docutils literal notranslate"><span class="pre">#4321</span></code>, a reference to <code class="docutils literal notranslate"><span class="pre">#1234</span></code>
|
||
in a migrated message could link to bpo <code class="docutils literal notranslate"><span class="pre">#1234</span></code> and bpo can
|
||
redirect to GitHub issue <code class="docutils literal notranslate"><span class="pre">#4321</span></code>, but new references to <code class="docutils literal notranslate"><span class="pre">#1234</span></code>
|
||
will link to GitHub PR <code class="docutils literal notranslate"><span class="pre">#1234</span></code> rather than GitHub issue <code class="docutils literal notranslate"><span class="pre">#4321</span></code>).
|
||
Manually having to specify a <code class="docutils literal notranslate"><span class="pre">bpo-</span></code> or <code class="docutils literal notranslate"><span class="pre">gh-</span></code> prefix is error prone.</p>
|
||
</li>
|
||
<li><strong>External issue links preservation.</strong> A number of websites,
|
||
mails, etc. link to bpo issues. If bpo is shut down, these links
|
||
will break. If we don’t want to break the links, we will have to
|
||
keep bpo alive and set up a redirect system that links to the
|
||
corresponding GitHub issue.<p>In addition, if GitHub shuts down, we won’t have any way to setup
|
||
redirects and preserve external links to GitHub issues.</p>
|
||
</li>
|
||
<li><strong>References preservation and updating.</strong> In addition to issue
|
||
references, bpo <a class="reference external" href="https://devguide.python.org/triaging/#generating-special-links-in-a-comment">converts a number of other references into links</a>,
|
||
including message and PR IDs, changeset numbers, legacy SVN
|
||
revision numbers, paths to files in the repo, files in tracebacks
|
||
(detecting the correct branch), and links to devguide pages and
|
||
sections.<p>Since Roundup converts references to links when messages are
|
||
requested, it is possible to update the target and generate the
|
||
correct link. This need already arose several times, for
|
||
example: files and HG changesets moved from <code class="docutils literal notranslate"><span class="pre">hg.python.org</span></code> to
|
||
GitHub and the devguide moved from <code class="docutils literal notranslate"><span class="pre">docs.python.org/devguide</span></code> to
|
||
<code class="docutils literal notranslate"><span class="pre">devguide.python.org</span></code>.</p>
|
||
<p>Since messages on GitHub are static, the links will need to be
|
||
generated and hardcoded during the migration or they will be lost.
|
||
In order to update them, a tool to find all references and
|
||
regenerate the links will need to be written.</p>
|
||
</li>
|
||
<li><strong>Roundup and bpo maintenance.</strong> On top of the aforementioned
|
||
changes to bpo and development of tools required to migrate to
|
||
GitHub issues, we will still need to keep running and maintaining
|
||
Roundup, both for our bpo instance (read-only) and for the Jython
|
||
and Roundup trackers (read-write).<p>Even if eventually we migrate all bpo issues to GitHub and we stop
|
||
maintaining Jython and Roundup, bpo will need to be maintained
|
||
and redirect to the corresponding GitHub issues.</p>
|
||
</li>
|
||
<li><strong>Bots maintenance.</strong> Since it’s not possible to customize GitHub
|
||
directly, it’s also necessary to write, maintain, and host bots.
|
||
Even if eventually we stop maintaining Roundup, the maintenance
|
||
burden simply shifted from Roundup to the bots. Hosting each
|
||
different bot also has a monetary cost.</li>
|
||
<li><strong>Using issue templates.</strong> Manually editing issue templates to
|
||
“remove texts that don’t apply to [the] issue” is cumbersome and
|
||
error-prone.</li>
|
||
<li><strong>Signal to noise ratio.</strong> Switching to GitHub Issues will
|
||
likely increase the number of invalid reports and increase
|
||
the triaging effort. This concern has been raised in the past
|
||
in a <a class="reference external" href="https://python.zulipchat.com/#narrow/stream/130206-pep581/topic/s.2Fn.20ratio">Zulip topic</a>.<p>There have been already cases where people posted comments on
|
||
PRs that required moderators to mark them as off-topic or
|
||
disruptive, delete them altogether, and even lock the
|
||
conversation (for example, <a class="reference external" href="https://github.com/python/cpython/pull/9099">this PR</a>.</p>
|
||
</li>
|
||
<li><strong>Weekly tracker reports and stats.</strong> Roundup sends weekly reports
|
||
to python-dev with a summary that includes new issues, recent
|
||
issues with no replies, recent issues waiting for review, most
|
||
discussed issues, closed issues, and deltas for open/closed/total
|
||
issue counts (for example, see <a class="reference external" href="https://mail.python.org/pipermail/python-dev/2019-May/157483.html">this summary</a>).
|
||
The report provides an easy way to keep track
|
||
of the tracker activity and to make sure that issues that require
|
||
attention are noticed.<p>The data collect by the weekly report is also used to generate
|
||
<a class="reference external" href="https://bugs.python.org/issue?@template=stats">statistics and graphs</a>
|
||
that can be used to gain new insights.</p>
|
||
</li>
|
||
<li><strong>bpo-related MLs.</strong> There are currently two mailing lists where
|
||
bpo posts new tracker issues and all messages respectively:
|
||
<a class="reference external" href="https://mail.python.org/mailman/listinfo/new-bugs-announce">new-bugs-announce</a>
|
||
and <a class="reference external" href="https://mail.python.org/mailman/listinfo/python-bugs-list">python-bugs-list</a>.
|
||
A new system will need to be developed to preserve this functionality. These MLs
|
||
offer additional ways to keep track of the tracker activity.</li>
|
||
</ul>
|
||
</section>
|
||
<section id="copyright">
|
||
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
|
||
<p>This document has been placed in the public domain.</p>
|
||
</section>
|
||
</section>
|
||
<hr class="docutils" />
|
||
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0595.rst">https://github.com/python/peps/blob/main/peps/pep-0595.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0595.rst">2023-09-09 17:39:29 GMT</a></p>
|
||
|
||
</article>
|
||
<nav id="pep-sidebar">
|
||
<h2>Contents</h2>
|
||
<ul>
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#resolution">Resolution</a></li>
|
||
<li><a class="reference internal" href="#motivation">Motivation</a></li>
|
||
<li><a class="reference internal" href="#roundup-advantages-over-github-issues">Roundup advantages over GitHub Issues</a></li>
|
||
<li><a class="reference internal" href="#improving-roundup">Improving Roundup</a></li>
|
||
<li><a class="reference internal" href="#pep-581-issues">PEP 581 issues</a></li>
|
||
<li><a class="reference internal" href="#migration-considerations">Migration considerations</a></li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
|
||
<br>
|
||
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0595.rst">Page Source (GitHub)</a>
|
||
</nav>
|
||
</section>
|
||
<script src="../_static/colour_scheme.js"></script>
|
||
<script src="../_static/wrap_tables.js"></script>
|
||
<script src="../_static/sticky_banner.js"></script>
|
||
</body>
|
||
</html> |