[Twisted-Python] Migrating Trac Tickets to GitHub issues
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
From what I can see, the servers are just restarted on an issue, but
Hi, I would like to re-start the conversation about migrating Trac tickets to GitHub issues. My main reason for doing this is to make it easier for people to contribute to Twisted. In CONTRIBUTING there is this info `GitHub doesn't provide adequate tooling for its community.` I don't know what is missing in GitHub and why overall Trac is better than GitHub issues. I know that GitHub Issues is simple and you can't save reports. What are problems are there with GitHub issues, which are blocking the migration? Please send your thoughts. Why you think that GitHub issues might be worst than Trac tickets :) ? -------- Below are the things that I things we will lose when migrating to GitHub Issues and which will require extra work. 1. We will no longer get the nice ticket reports. I don't know how to get something like this just using GitHub... and I think that we will need a separate web page which uses GitHub API to create the reports. 2. We might lose the owners / authors of some comments as there might not be a maping from Trac to GitHub. This might be mititage as we are already using GitHub for login. 3. There is extra one-time work required to do the actual migration, and decide how to translate Trac ticket attributes to GitHub Issue attributes. We might not get consensus on how to migrate the metadata and this can be a blocker. 4. We will no longer get the weekly reports and need more work to reimplement them based on GitHub. 5. Highscores will stop counting the contribution, and it needs more work to reimplement it on top of GitHub. I have hacked the highscores project and I can change it to work both historic Trac data and new GitHub data. ---------------- Below are my arguments for migrating to GitHub issues: 1. With Twisted tickets/PR only handled on GitHub you can have contributions which are done only by sending a PR, without creating an issue. You find a bug, you fix it and send a PR. You no longer need to go to Trac and create a ticket and then do all the cross-links copy and pasting. 2. We no longer have the review history in Trac, and the review discussions are split between Trac and GitHub. I think that in the future we will move more review discussions in GitHub. Having all the discussion in a single place will make it easier to search for something. You no longer need to search GitHub and Trac tickets. 3. With tickets on GitHub we should simplify the infrastructure. I feel that lately there was not much time from current Twisted dev to take care of Twisted infra. there is no time to investigate what is wrong. I think that Twisted dev should focus on Twisted code and not spend time with the ticketing infrastructure. 4. With tickets in GitHub, we don't need extra tooling to close a ticket when a PR is merged. 5. With tickets in GitHub I assume that a lot of contributors will only have to care about a single management tool: GitHub. They will no longer have to learn about Trac, how Trac keywords work for a ticket and how a workflow is implemented in Trac for Twisted.
Thanks, PS: For my private project I am still using Trac for issues and GitHub for PR and manage the tools to keep them in sync. I am using the Trac ticket workflows with a dedicated state for a ticket when it needs a review or when a review was done and it needs changes. -- Adi Roiban
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 30 September 2017 at 22:15, Adi Roiban <adi@roiban.ro> wrote: [snip]
[snip] 6. We will no longer get the tickets pending review reported on IRC. Beside reimplementing this based on GitHub issues, there might be a lot of work in getting consensus about how to mark a PR as needs review. There is this thread which talks about how to implement the review workflow in a PR https://twistedmatrix.com/pipermail/twisted-python/2016-May/030333.html Maybe before migrating to GitHub issues, we should first agree on this issue. [snip] -- Adi Roiban
![](https://secure.gravatar.com/avatar/469df05f5dfd5b75fb3cb3a0868d36bf.jpg?s=120&d=mm&r=g)
On Sat, Sep 30, 2017 at 2:15 PM, Adi Roiban <adi@roiban.ro> wrote:
I think migrating Twisted issues from Trac to GitHub is a good idea, and will make it easier for people to interact with the project.
1. We will no longer get the nice ticket reports.
This is true. However, I will make a guess that not many people are actively interacting with the Twisted project, and not really actively following bug activity in Trac. So there is some loss there, but I think the project would survive and go on. One thing that I would like to point out is that the Buildbot project was using Trac for their issue tracker, and then decided to migrate their issues to GitHub. They worked on a tool called trac2github that allowed them to migrate tickets from Trac to GitHub, preserving history, and also creating a link back to the original Trac issue: https://lists.buildbot.net/pipermail/devel/2017-March/012341.html For the buildbot project, I think this approach as worked out, and the project has continued. If the Twisted project decides to switch to GitHub for issues, then possibly buildbot's scripts and experience can be used as a template for such a migration. -- Craig
![](https://secure.gravatar.com/avatar/3d37232726396a1d3c7412dd915095ea.jpg?s=120&d=mm&r=g)
Currently, GitHub Issues don't allow for non-committers to make modifications to categories, milestones, edit the original ticket description, or close tickets. This kinda sucks, because it makes the pool of triagers smaller, and also makes most obvious review queue methods harder (adding a category). I think Mark Williams or someone has hacked up a bot to sidestep this, but... again, contributor effort to get that past the line. - Amber
![](https://secure.gravatar.com/avatar/469df05f5dfd5b75fb3cb3a0868d36bf.jpg?s=120&d=mm&r=g)
On Sun, Oct 1, 2017 at 3:30 AM, Amber Brown <hawkowl@atleastfornow.net> wrote:
Are there enough non-committers to Twisted who are actively doing this right now, to make this as big an issue as you are claiming? My guess is no. Other projects related to klein and treq are using GitHub to track issues instead of Trac. Do those projects have problem with non-committers triaging issues, despite the inability to create/modify categories/milestones, etc.? -- Craig
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
"Submit for review" is such an action, so, yes.
Yes. It's a huge issue. If I didn't have a regular task to manually comb those trackers I don't know if anything would get looked at; I have nothing to point others at other than "just randomly peruse the list of open issues". Trac is hot garbage but I miss it every time I have to look at my not-quite-working ad-hoc query to figure out what the workflow state on everything there is. That said: if we could get this ALL into github, then we could write ONE query that would be the full review queue for all Twisted org projects. And that would be amazing, a huge upgrade from what we've got now. Finishing txghbot is probably not a ton of work, but it's not zero either. -g
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
The major missing feature, as discussed in the PR thread, is the ability to record the separate workflow state of "needs review" / "needs feedback addressed" as distinct from "open" / "closed". A bot that could do this would address more or less the entire issue.
One issue which I haven't seen raised here is the need to maintain a redirection service, to ensure that the massive amount of information currently recorded in commit messages and emails linking to existing trac issues is not lost.
While, in general, I strongly agree with this, and I would personally very much like to operate less infrastructure, there is the fact that the twistedmatrix.com <http://twistedmatrix.com/> website has served as a very important dogfooding resource for us in the past. We've found and fixed dozens of bugs in Twisted due to our constant, intense use of it. That said, this is not really an argument against doing this. Maybe if we didn't have to operate something as old and clunky as Trac we could invest our dogfooding effort in new, cool web toys where the effort was writing and debugging code using Twisted and not shell scripts to restart zombie processes. I just think it's important to consider how the developer community can continue to use Twisted itself as part of this process.
Thanks for driving this effort forward! I look forward to hearing Mark pipe up in this thread (hint, hint)...
![](https://secure.gravatar.com/avatar/c194a4d2f2f8269aa052942e87985198.jpg?s=120&d=mm&r=g)
On 30 September 2017 at 22:15, Adi Roiban <adi@roiban.ro> wrote: [snip]
[snip] 6. We will no longer get the tickets pending review reported on IRC. Beside reimplementing this based on GitHub issues, there might be a lot of work in getting consensus about how to mark a PR as needs review. There is this thread which talks about how to implement the review workflow in a PR https://twistedmatrix.com/pipermail/twisted-python/2016-May/030333.html Maybe before migrating to GitHub issues, we should first agree on this issue. [snip] -- Adi Roiban
![](https://secure.gravatar.com/avatar/469df05f5dfd5b75fb3cb3a0868d36bf.jpg?s=120&d=mm&r=g)
On Sat, Sep 30, 2017 at 2:15 PM, Adi Roiban <adi@roiban.ro> wrote:
I think migrating Twisted issues from Trac to GitHub is a good idea, and will make it easier for people to interact with the project.
1. We will no longer get the nice ticket reports.
This is true. However, I will make a guess that not many people are actively interacting with the Twisted project, and not really actively following bug activity in Trac. So there is some loss there, but I think the project would survive and go on. One thing that I would like to point out is that the Buildbot project was using Trac for their issue tracker, and then decided to migrate their issues to GitHub. They worked on a tool called trac2github that allowed them to migrate tickets from Trac to GitHub, preserving history, and also creating a link back to the original Trac issue: https://lists.buildbot.net/pipermail/devel/2017-March/012341.html For the buildbot project, I think this approach as worked out, and the project has continued. If the Twisted project decides to switch to GitHub for issues, then possibly buildbot's scripts and experience can be used as a template for such a migration. -- Craig
![](https://secure.gravatar.com/avatar/3d37232726396a1d3c7412dd915095ea.jpg?s=120&d=mm&r=g)
Currently, GitHub Issues don't allow for non-committers to make modifications to categories, milestones, edit the original ticket description, or close tickets. This kinda sucks, because it makes the pool of triagers smaller, and also makes most obvious review queue methods harder (adding a category). I think Mark Williams or someone has hacked up a bot to sidestep this, but... again, contributor effort to get that past the line. - Amber
![](https://secure.gravatar.com/avatar/469df05f5dfd5b75fb3cb3a0868d36bf.jpg?s=120&d=mm&r=g)
On Sun, Oct 1, 2017 at 3:30 AM, Amber Brown <hawkowl@atleastfornow.net> wrote:
Are there enough non-committers to Twisted who are actively doing this right now, to make this as big an issue as you are claiming? My guess is no. Other projects related to klein and treq are using GitHub to track issues instead of Trac. Do those projects have problem with non-committers triaging issues, despite the inability to create/modify categories/milestones, etc.? -- Craig
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
"Submit for review" is such an action, so, yes.
Yes. It's a huge issue. If I didn't have a regular task to manually comb those trackers I don't know if anything would get looked at; I have nothing to point others at other than "just randomly peruse the list of open issues". Trac is hot garbage but I miss it every time I have to look at my not-quite-working ad-hoc query to figure out what the workflow state on everything there is. That said: if we could get this ALL into github, then we could write ONE query that would be the full review queue for all Twisted org projects. And that would be amazing, a huge upgrade from what we've got now. Finishing txghbot is probably not a ton of work, but it's not zero either. -g
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
The major missing feature, as discussed in the PR thread, is the ability to record the separate workflow state of "needs review" / "needs feedback addressed" as distinct from "open" / "closed". A bot that could do this would address more or less the entire issue.
One issue which I haven't seen raised here is the need to maintain a redirection service, to ensure that the massive amount of information currently recorded in commit messages and emails linking to existing trac issues is not lost.
While, in general, I strongly agree with this, and I would personally very much like to operate less infrastructure, there is the fact that the twistedmatrix.com <http://twistedmatrix.com/> website has served as a very important dogfooding resource for us in the past. We've found and fixed dozens of bugs in Twisted due to our constant, intense use of it. That said, this is not really an argument against doing this. Maybe if we didn't have to operate something as old and clunky as Trac we could invest our dogfooding effort in new, cool web toys where the effort was writing and debugging code using Twisted and not shell scripts to restart zombie processes. I just think it's important to consider how the developer community can continue to use Twisted itself as part of this process.
Thanks for driving this effort forward! I look forward to hearing Mark pipe up in this thread (hint, hint)...
participants (4)
-
Adi Roiban
-
Amber Brown
-
Craig Rodrigues
-
Glyph