Update: Transition from RT to GitHub [FAQ]

From: Sawyer X

Date: October 11, 2019 01:34

Subject: Update: Transition from RT to GitHub [FAQ]

Message ID: CAMvkq_QRbAEOYqH590RYe=3RB6USXezCUKTwFxJm=Z_Fo8FQWg@mail.gmail.com

October 11, 2019 01:34Update: Transition from RT to GitHub [FAQ]

Hi all, 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. Sincerely, Sawyer X **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 perlbug@perl.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 the mailbox. **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 submit issues. **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 perl5-security-report@perl.org. **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.



