Confirm format of migrated issues from Trac tickets

[ronaldtse]

@rjsparks could you please help check if the format of migrated issues make sense? Thanks.

• mailarchive
• datatracker
• dmarc1
• emailcore1
• tsvwg1
• xml2rfc1
• vocabulary_design_team_2013_20171

Originally posted by @HassanAkbar in https://github.com/ietf-ribose/svn-github-convert/issues/18#issuecomment-949655067

[rjsparks]

It will be easier to get a good review of these once repositories are created that have the code populated, and the links in the tickets to the code work.

[rjsparks]

My early impressions are that this is all on the right track. There are occasional issues where trac formatting (or more specifically, the lack of trac formatting) lead to odd presentation when interpreted with markdown, but the information is there, and if it's important, the ticket can be edited to straighten out the presentation.

Example: https://github.com/ietf-svn-conversion/mailarchive/issues/3137

[rjsparks]

Double-checking - I don't think what's linked above (as of right now anyhow) has this implemented? https://github.com/ietf-ribose/svn-github-convert/issues/18#issuecomment-953580005

[ronaldtse]

Double-checking - I don't think what's linked above (as of right now anyhow) has this implemented? #18 (comment)

I believe this is implemented: https://github.com/ietf-ribose/tractive/blob/8318121813dcf96f7232fcd469514c6c7a652d79/spec/support/helpers/ticket_compose.rb#L33

However the latest repos may not have been updated with the "component:" labels yet. The mailarchive issues were last migrated a couple weeks ago.

We will ping again for a review once the code and issues are integrated into the migrated repos.

[jennifer-richards]

Another incorrectly formatted description: in ietf-svn-conversion/xml2rfc1#658, there is a <li> near the end of the original description that is rendered as an HTML list item ("Apparently, there there needs to be a..."). It ought to be shown as the literal \<li> characters.

[ronaldtse]

@jennifer-richards thanks for raising this interesting issue, this was always a worry...

In the case of the <li>: the end goal is to either to wrap it with backticks or escape the angular brackets for GitHub to recognise it is not HTML.

The thing is, that the determination of escaping <li> will involve non-regex parsing because the original sin stems from the tickets being in the Trac WikiFormatting syntax (i.e. their document model), and we are now migrating it into Markdown which is a different document model.

The current conversion code uses regexes for conversion, it won't cut it: https://github.com/ietf-ribose/tractive/blob/main/lib/tractive/migrator/converter/twf_to_markdown.rb

Need to think...

[rjsparks]

I don't think it will be worth the cost to develop a completely robust trac wikiformat to github markdown converter. If there are classes of things that we can get with simple substitutions, fine, but lets please not go hunting for the point of diminishing returns while building them.

The raw text is available and can be edited after the fact (by people with the right permissions). For tickets where markdown doesn't do the right thing and it matters, a human can intervene with an edit after migration.

(@JayDaley: tagging you in this as it is a decision that interprets the implied scope of the RFP)

[jennifer-richards]

That seems reasonable to me.

[ronaldtse]

All done, closing.