Add support for keywords migration as labels

[btlogy]

Trac tickets have a keywords field which are "useful for searching and report generation" about tickets related to a the same topic without having to create a component or a milestone (which may requires some privileges).

As today, there are already a few fields from Track tickets which are converted in Gitea labels:

• component
• priority
• resolution
• severity
• type
• version

From here:

trac2gitea/importer/label.go

Lines 42 to 70 in f013209

	// DefaultComponentLabelMap retrieves the default mapping between Trac components and Gitea labels
	func (importer *Importer) DefaultComponentLabelMap() (map[string]string, error) {
	return importer.defaultLabelMap(trac.Accessor.GetComponents)
	}
	// DefaultPriorityLabelMap retrieves the default mapping between Trac priorities and Gitea labels
	func (importer *Importer) DefaultPriorityLabelMap() (map[string]string, error) {
	return importer.defaultLabelMap(trac.Accessor.GetPriorities)
	}
	// DefaultResolutionLabelMap retrieves the default mapping between Trac resolutions and Gitea labels
	func (importer *Importer) DefaultResolutionLabelMap() (map[string]string, error) {
	return importer.defaultLabelMap(trac.Accessor.GetResolutions)
	}
	// DefaultSeverityLabelMap retrieves the default mapping between Trac severities and Gitea labels
	func (importer *Importer) DefaultSeverityLabelMap() (map[string]string, error) {
	return importer.defaultLabelMap(trac.Accessor.GetSeverities)
	}
	// DefaultTypeLabelMap retrieves the default mapping between Trac types and Gitea labels
	func (importer *Importer) DefaultTypeLabelMap() (map[string]string, error) {
	return importer.defaultLabelMap(trac.Accessor.GetTypes)
	}
	// DefaultVersionLabelMap retrieves the default mapping between Trac versions and Gitea labels
	func (importer *Importer) DefaultVersionLabelMap() (map[string]string, error) {
	return importer.defaultLabelMap(trac.Accessor.GetVersions)
	}

It would make sense to use a new type of label to migrate the keywords.
Though, because of their "free" natures, their number might be quite large and generate a long list of label in Gitea, we might want to enable this feature only when requested and also propose a (default?) prefix such as keyword/.

[btlogy]

The first idea is obviously to create a label per keyword...
But the keywords being a free string in Trac, this will result in creating 1846 new labels in the case I'm working on!
We may consider an alternative implementation which would just add the keywords string at the end of the description!
But this approach could make it harder to query the issues (not sure how the Gitea/Forgejo search feature will work it out).

[btlogy]

As suggested my @meejah in the last N&B, Twisted has likely faced some similar concern when they have decided to migrated from Trac to GitHub.
In their case, they have chosen to add those keywords as part of some searchable metadata in the description (e.g. twisted/twisted#11338).
But I'm not sure how those data are searched...

[btlogy]

I've tried to query those Twisted searchable metadata, but yet failed to find any issues where they would have used those keywords...

In addition, as far as I can tell, search queries are not as advanced on Forgejo as on GitHub and seem to be limited to the title of the issues (not covering the description or the comment)!

[meejah]

This is the repo you want, I believe: https://github.com/chevah/trac-to-github

[meejah]

In addition, as far as I can tell, search queries are not as advanced on Forgejo as on GitHub and seem to be limited to the title of the issues (not covering the description or the comment)!

Please add this as another "con" for Forgejo / codeberg.

[btlogy]

In addition, as far as I can tell, search queries are not as advanced on Forgejo as on GitHub and seem to be limited to the title of the issues (not covering the description or the comment)!

Please add this as another "con" for Forgejo / codeberg.

If we were to compare with GitHub, advanced issue search queries (e.g.: with regex) and code search would indeed be a con for Gitea/Forgejo and any SaaS serving them indeed. But the main idea was to compare Gitea/Forgejo on self-hosted vs on SaaS.

Never the less, this is an interesting user story to cover assuming Trac was allowing to search in comments. And I was surprised by the fact that Forgejo/Gitea search did not seem to cover it.

As it turned out, this feature is available in the latest Forgejo running now on Codeberg. And not yet in our self-hosted instance in NixOS v24.05. But should be available this month in v24.11.

[btlogy]

Assuming we can search in comments (see above), we then could decide to dump the keywords as metadata in the description.

[btlogy]

This is the repo you want, I believe: https://github.com/chevah/trac-to-github

Thank you @meejah: this tool is actually parsing the keywords as labels:

https://github.com/chevah/trac-to-github/blob/f7f9c35c9c778a54c8dcf4357e74e6e210a24280/ticket_migrate.py#L778-L812

[btlogy]

In addition, as far as I can tell, search queries are not as advanced on Forgejo as on GitHub and seem to be limited to the title of the issues (not covering the description or the comment)!

Please add this as another "con" for Forgejo / codeberg.

I've verified this apparent lack of "search in comments" and found out that is was caused by a broken indexer (bleeve by default) on the Forgejo instance we are using (it was working as expected on Gitea).
I've fixed it, so we could also search for metadata if needed, w/o waiting for a more recent version of Forgejo.

This being said, the migration from keywords to labels is working well enough IMHO.
So we may not need to dump metadata to search for those keywords (maybe still needed for something else, but nothing obvious to me yet).