Front page | perl.perl5.porters |
Postings from October 2019
Update: Transition from RT to GitHub [FAQ]
From: Sawyer X
October 11, 2019 01:34
Update: Transition from RT to GitHub [FAQ]
Message ID: CAMvkq_QRbAEOYqH590RYe=3RB6USXezCUKTwFxJm=Z_Fo8FQWg@mail.gmail.com
Thank you for all the patience and all of the feedback on these
threads. I tried to pick up all of the issues raised from the various
emails and respond to them in one place below. If I have missed
something important, please let me know.
The driving reasons for this change are that we spend a great deal of
time managing infrastructure on volunteer time, and it does not get
the attention that it deserves, which creates risk for us all. Our
goal is to focus on our core competency, which is maintaining Perl 5.
Right now, we do not have spare capacity to continue supporting RT.
On October 18, we will begin the conversion of all RT cases to GitHub
issues. Existing issues in RT will be unavailable until the conversion
completes. (Expected duration 2-3 days).
The move of the primary git repo to GitHub will probably happen that
weekend too. The mirroring will be reversed, and
https://perl5.git.perl.org/ will become a read-only mirror. We need to
work out some details, which is why this change is tentative.
**Issue:** I won't create an account on a major service with a complex
EULA. I think we shouldn't support that.
**Response:** Each person has their limitations, but we cannot
accommodate all of them with our restricted resources and capacity. If
you are unwilling to join GitHub, you may submit a patch or work with
another person who has an account. However, our ability to support you
would be limited.
**Issue:** Will there be a persistent migration from RT to GitHub?
**Response:** No. After the migration, old RT links will respond with
a 301, redirecting you to the new GitHub ticket. The header of the
migrated ticket will point you to a read-only copy of the original
case frozen at the time of migration. The system of record will be on
our GitHub repo.
**Issue:** Why didn't you use a self-hosted alternative to RT?
**Response:** While the self-hosted tool might meet our needs now, it
has the risk of aging, and a requirement of ongoing maintenance just
like RT did. Additionally, the setup and hosting costs remain.
**Issue:** Why didn't you use an alternative service instead of GitHub?
**Response:** We feel GitHub already has a strong following in the
Perl community. Over 95% of the repositories referred to in CPAN are
on GitHub. Having both repositories on the same service may also
provide additional benefits from cross-linking, etc.
**Issue:** What about rt.cpan.org?
**Response:** CPAN RT is out of scope for this project.
**Issue:** What about perlbug on legacy versions of perl?
**Response:** When you remove known contributors from
firstname.lastname@example.org, there are very few non-spam emails. We plan to do a
one-time autoresponder to each new email address and redirect incoming
emails to a monitored mailbox. In the future, we may stop monitoring
**Issue:** What about perlbug on new versions of perl?
**Response:** The current proposal is to change perlbug to provide a
template for you to enter your information in and then direct you to
GitHub to copy/paste your submission.
**Issue:** How will we ensure new tickets provide sufficient information?
**Response:** GitHub provides the ability to specify one or more
ticketing templates for people who want to submit a new issue.
**Issue:** GitHub uses JS for logins! I don't trust JS.
**Response:** GitHub also provides an API that can be accessed once
you set up a token. Take a look at Net::GitHub::V3.
**Issue:** You should add an anonymous service to which people can
**Response:** One of our most significant maintenance issues is spam.
We prefer authenticated submissions (whether they include a name or
not) because they reduce the spam we will receive considerably.
**Issue:** Where will security issues go?
**Response:** p5p has been granted a non-profit status by GitHub,
which allows us to have multiple private repositories with several
accounts attached to it. We will have a private repository/issues
system in the same org. It will be possible to move issues between the
public and private repository as needed.
**Issue:** How will security issues be reported?
**Response:** Security issues will continue to be reported at
**Issue:** When pull requests are enabled, what will the merge policy be?
**Response:** A rebase and push policy can be enforced just like we
already do with our existing repository.