These days I am not a heavy user, so please discount these observations as you see fit.
If I am not mistaken, David H's bullet 1 is affected by bullet 2. Namely, *if* you are going to copy from Trac to GitHub, and *if* wherever that copy gets made is used to continue discussions on those points, then all Trac activities cease as of the change-over day, to be replaced by GitHub. Which I think would be most time- and cost-effective. This next may sound radical but as a practical matter, if it is only 174 tickets, this need not be a huge deal. If there are people spending 50% of their time reading Trac tickets, then maybe it needs to be done just right. But for 174 tickets, many of them closed, I think even if you don't make the numbers track with trac (sorry), the total number of impacts is going to be small on day 1, and vanishingly small after a year. OK, 2 years. 1) Step one is copying the tickets. As mentioned, there are at least 4 GitHub projects and this Slack page lists a number of approaches, some of which look quite mature: https://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issues. Copy the tickets at the end of the current repository (existing ticket #$), making sure Trac's closed tickets are closed in GitHub. (I'm not sure you'll be able to save the dates of all the entries with these tools; but if it's easy, you could copy the dates as the first line of each entry/comment. Copying the original Trac # wouldn't hurt either.) 1A) If you absolutely had to clean up all those links, somewhere in the transition pipeline write a script to convert all the links in those 174 tickets to point to the new GitHub ticket/comment location, if that isn't handled automagically by the conversion tool. 2) Either manually or via a script, create an entry for the last comment of each existing Trac ticket that says "Discussion and maintenance of this issue has been moved to <new_uri_for_old_trac_ticket_n>." 3) If you feel compelled to have a forward reference after the Trac repository goes entirely away, use a separate repository to copy the 174 tickets (preserving the ticket number) with just the title of the ticket, and an entry that says the same thing as above. Or create a ticket-mapping entry. But if you count the number of open Trac tickets, the number of comments being actively made on them, the number of people making them, and the number of cross references those people need to follow, I propose it is not going to be a major crisis for everyone to adjust to the new location in the new repository, especially given the titles are the same and the previous Trac (or a copy of it) has a forward lookup/reference. I don't think the fact that all of this could change again someday is an argument that says the new numbers have to match the old. Either way all the numbers/references might have to change again. It would definitely be ideal if numbers were unique and matched; but even if some were duplicated and they didn't match, you will always be able to manually recognize that for all the new github tickets that came from trac (from #$+1 to #$+174 in the github repository), the internal numbers will need to be mentally cross-referenced into the new Github numbers (original number minus #$). This could be done automatically at the time of the next conversion, if it isn't done this time around, or even manually as desired on a per ticket and per comment basis. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-404956902
