Feedback for Trac ticlets to GitHub Issues migration
Hi, I am writing here to get some feedback about migration Twisted Trac Ticket to GitHub Issues. In short, try to spend more time doing Twisted development and less time developing custom tools and doing sysadmin work. The main reason for the migration is that we don't have enough people/time to manage the Trac instance or improve the dev tools around Trac. With GitHub issues it should be easier to reuse tools created by others for GitHub. Also, I think that having Pull Requests an GitHub with the GitHub own review queue/report and a separate set of report in Trac is extra "office" work We are already doing Trac authentication via Github. Anyone over here who is against migrating the Twisted Trac tickets to GitHub ? I see Trac has about 10300 tickets and GitHub PR is now at 1672 . We can migrate with keeping the same ID for the majority of the tickets. With the migration the original author of a ticket/comment is lost. This is a security feature in GitHub. Also, it's not trivial to get all the Trac accounts mapped to GitHub accounts. We can keep the existing Trac in read-only mode for some time. And it can (and will be) linked from Github Issues For the attachments, they can be hosted on a static HTTP site like `trac-attachments.twisted.org` (which can be hosted by Github pages) and linked from GitHub Issues. Components, Priority, and keywords can be converted to GitHub Issue labels. "Owned by" can be converted to GitHub issue assignee ... if we have a mapping :) The milestones can be converted to GitHub Issue milestones "Branch" trac ticket custom field can be used to detect a link to a GitHub PR ---------- Until recently the Twisted Trac instance was running on Ubuntu 16.04 ... and I don't know how often it is updated. Now, Trac is hosted on an Azure VM with Ubuntu 20.04... but we don't have time to look after it. --------- If the majority of Twisted devs agree to migrate to GitHub we can look into the execution details. My company has recently migrated from Trac to GitHub and I can ask my colleague to help with the Twisted migration. PS: later we can also look at migrating the Trac Wiki to GitHub Wiki PS: there is also planning to have a simpe (static) presentation site for Twisted https://github.com/twisted/twisted.github.io/pull/6 .. to replace the current site that is hosted via Trac Wiki with heavy customization Regards -- Adi Roiban
it's a good idea, I found people would ask questions about a PR having clearly not read the linked Trac ticket, trac just isn't getting used other than the requirement to create a ticket for each PR On 11/11/2021 8:33 pm, Adi Roiban wrote:
Anyone over here who is against migrating the Twisted Trac tickets to GitHub ?
On Thu, Nov 11, 2021 at 4:34 AM Adi Roiban <adiroiban@gmail.com> wrote:
Hi,
I am writing here to get some feedback about migration Twisted Trac Ticket to GitHub Issues.
In short, try to spend more time doing Twisted development and less time developing custom tools and doing sysadmin work.
The main reason for the migration is that we don't have enough people/time to manage the Trac instance or improve the dev tools around Trac. With GitHub issues it should be easier to reuse tools created by others for GitHub.
Also, I think that having Pull Requests an GitHub with the GitHub own review queue/report and a separate set of report in Trac is extra "office" work
We are already doing Trac authentication via Github.
Anyone over here who is against migrating the Twisted Trac tickets to GitHub ?
I see Trac has about 10300 tickets and GitHub PR is now at 1672 . We can migrate with keeping the same ID for the majority of the tickets.
With the migration the original author of a ticket/comment is lost. This is a security feature in GitHub. Also, it's not trivial to get all the Trac accounts mapped to GitHub accounts.
Maybe rather than losing this (and any other metadata) it can be preserved as non-canonical metadata. For example, maybe each issue description and comment can end with an easily machine-identifiable block that encodes the information from trac. The information may not be especially interesting in the day-to-day development of Twisted but it could potentially be interesting for certain investigations - for example, I have often been interested in finding out who made some change or comment that I could not understand so I could find them and talk to them about it. Maybe this kind of thing is already done by the migration tool anyway and you were only talking about canonical GitHub metadata, though? I've seen projects migrated to, eg, GitLab where the migration tool leaves a text blurb with original author information at the bottom, for example.
We can keep the existing Trac in read-only mode for some time. And it can (and will be) linked from Github Issues
If *all* of the trac metadata gets encoded into GitHub *somehow* then maybe this Trac deployment doesn't have to be maintained for very long. I know this may mean extra work for the migration. However, I'd ask that you strongly weigh that cost against what's being lost if this isn't done. Twisted has decades of history at this point. That represents a massive investment from many people. Apart from the practical value that is lost if metadata about those contributions is thrown away, it also seems disrespectful to the people who put in that investment and sends a certain signal about how current and new contributions are likely to be valued by future project maintainers. Jean-Paul
Hi Ian and Jean-Paul Thanks for the feedback. On Thu, 11 Nov 2021 at 13:26, Jean-Paul Calderone <exarkun@twistedmatrix.com> wrote:
On Thu, Nov 11, 2021 at 4:34 AM Adi Roiban <adiroiban@gmail.com> wrote:
[snip]
With the migration the original author of a ticket/comment is lost. This is a security feature in GitHub. Also, it's not trivial to get all the Trac accounts mapped to GitHub accounts.
Maybe rather than losing this (and any other metadata) it can be preserved as non-canonical metadata. For example, maybe each issue description and comment can end with an easily machine-identifiable block that encodes the information from trac.
The information may not be especially interesting in the day-to-day development of Twisted but it could potentially be interesting for certain investigations - for example, I have often been interested in finding out who made some change or comment that I could not understand so I could find them and talk to them about it.
Great feedback. The current code migrated all possible metadata to GitHub Issue dedicated fields like labels , asigneed, milestone ... and add a human readable info for the metadata that couldn't be migrated to GitHub metadata. But I think that keeping all metadata in the description will help. The current tool migrate a ticket something like this https://github.com/chevah/compat/issues/133 Without any machine readable metadata in the comment. And with GitHub resolution closed:fixed converted into a label.
Maybe this kind of thing is already done by the migration tool anyway and you were only talking about canonical GitHub metadata, though? I've seen projects migrated to, eg, GitLab where the migration tool leaves a text blurb with original author information at the bottom, for example.
I need feedback regarding the ticket ID mapping. We have 2 options. Option A - Create a new repo Pros: All trac ID can be preserved to GitHub IDs Cons: All existing twisted/twisted PR will be hosted in a separate repo (twisted/twisted-archive) Option B - Migrate over the existing repo Pros: You still have all the 1670 PR in the same repo Cons: Trac tickets up to 1670 will not have a direct mapping to GitHub issue IDs
We can keep the existing Trac in read-only mode for some time. And it can (and will be) linked from Github Issues
If all of the trac metadata gets encoded into GitHub *somehow* then maybe this Trac deployment doesn't have to be maintained for very long.
I know this may mean extra work for the migration. However, I'd ask that you strongly weigh that cost against what's being lost if this isn't done. Twisted has decades of history at this point. That represents a massive investment from many people. Apart from the practical value that is lost if metadata about those contributions is thrown away, it also seems disrespectful to the people who put in that investment and sends a certain signal about how current and new contributions are likely to be valued by future project maintainers.
Thanks again for the feedback. My plan is to not lose any metadata or attachments. I have created an issue to make sure this is not forgotten https://github.com/chevah/trac-to-github/issues/17 I will wait over the weekend to receive more feedback about Option A or Option B :) The plan is then to do a testing migration over a testing repo, get a round of feedback and then the actual migration only after that. Regards -- Adi Roiban
On 12/11/2021 2:52 am, Adi Roiban wrote:
Option B - Migrate over the existing repo Pros: You still have all the 1670 PR in the same repo Cons: Trac tickets up to 1670 will not have a direct mapping to GitHub issue IDs
this is the preferred option IMHO as it is less disruptive to current work many GitHub PRs have a link to a matching Trac issue as their first comment. Is it possible to merge them?
participants (3)
-
Adi Roiban -
Ian Haywood -
Jean-Paul Calderone