moving trac tickets to GitHub

[sa2ajj]

Rationale

easier linking of incoming PRs to existing tickets

Trac Ticket Fields (and mapping)

• summary (=> title)
• reporter (=> bb-bot)
• description (=> body)
• type (=> ignore)
• priority (=> ignore)
• status (=> ignore)
• milestone (=> create and migrate)
• version (=> ignore)
• keywords (=> ignore)
• CC (=> leave a comment in the original ticket with the link on GH)

Milestones to migrate

• 0.9.0
• 0.9.1
• ​0.9+
• ​1.0+
• ​2.0+

Plan

1. make sure that the above list of milestones is all we want to move
2. run the script (being developed in ​https://github.com/buildbot/trac2gh) for these milestones
3. the description of the ticket is converted using the code mentioned in the comments
4. each user (reporter, owner, cc) is mentioned in the newly created issue if their e-mail address is public and found on GitHub
5. each migrated issue is closed and a comment migrated to GitHub <link #XXX> is added
6. review and decide what to do with the rest of open tickets @ trac

Open Items

• wiki links -> keep the links to BB trac?
• formatting? try to convert to Markdown? render HTML and use it as is?
• ticket history -> copy in the second comment?
• attachments -> GH does not have the feature

What else to have?

<Express your requirements and/or wishes here>

• Need some kind of labeling to sort the features that are in eight but not in nine.

FYI

GitHub

Ticket Fields

• title
• body
• assignees
• milestone
• labels

Other

• ​user searches allow to find users should they make their e-mail addresses public
• GitHub has projects, it might be a good idea to use them.

[dustin]

From today's meeting:

• AGREED: will migrate only 0.9+ bugs, but with the proviso that we keep the old data accessible somewhere (djmitche, 16:45:54)
• AGREED: migrated issues are owned by bb-bot, with author information in the first comment (djmitche, 16:50:00)

[sa2ajj]

an update:

• got the stuff (everything in the filesystem)
• got the db dump (to play around)
• got the required eggs

next steps:

• get a local instance of trac
• play with it (see how API works)
• try to get a local instance of bb trac
• try to play with it to see how ticket API works...
• outline what needs to be on the GitHub side API

[sa2ajj]

description is updated with field information

[tardyp]

I think labels are good for most of the things.

Frankly versions are not that useful to me as often bugs which are marked 0.9.0bx are anyway seen in the master branch.

So I think we would be good enough if we have one label per stable branch that we maintain. That would be 0.8.x, 0.9.0 and 0.9.x (or master)

while writing that text, I realize that this is exactly the same as the milestone.

for CC, people are automatically CCed in github when @mentioned. So I would suggest to map that with a last comment like: Following people were in the CC list of the original trac bug @user1 @user2 Obivously we will have to map trac users to gh users to make that work.

For keywords, I have not been very happy with the way trac handle keywords. They are not easily searchable unless you only stick with one keyword. I dont think we are really strict at putting keywords on trac. Probably starting from scratch and re-labelling manually would be better.

For projects, I don't understand very well the use, I think this is more meant to be mapped with Scrumm's sprints. Not sure if we are a scrumm team :)

m2c

Thanks for looking into that, this is very good progress!

[sa2ajj]

The problem with CC is that I do not see a way to find a user by e-mail. So what I have in mind is to add a comment on an exported ticket "The ticket is migrated to GitHub<link>, please follow the progress there."

[sa2ajj]

And, btw, my next step is to play [a bit] with projects to see if they can actually help us (no matter whether we are a scrum team :))

[dustin]

Of the named attributes, I think "milestone" is the most important, as it gives an indication of when we expect to close a particular issue.

We had a flurry of using keywords to try to divide up responsiblities in the project (MAINTAINERS.txt), but it never really went anywhere, and I think most 0.9.x tickets aren't tagged. So that can probably be ignored.

Mapping trac to github users is probably difficult and, even if possible, not very effective. I like the suggestion to leave a final comment in Trac, instead.

Projects are cool, and we might later find a use for them, but I don't see them mapping to anything available in Trac.

[sa2ajj]

Oops, forgot to add a comment. The description changes include:

• re-formatting (now it looks almost perfect)
• open questions (attachments, history, BB wiki links)
• ticket formatting: convert to markdown or?..

[sa2ajj]

User searches are possible

[sa2ajj]

​https://github.com/hinnerk/Trac2Gollum offers a simple trac markup to markdown markup translation.

[sa2ajj]

current count -- 100 tickets

[sa2ajj]

ok, that's the wrong count: all open (check-check) tickets.

let's run the "importer" with the milestones listed above.

[sa2ajj]

looks like the above milestones result in 35 tickets

[sa2ajj]

looking at the conversion results of ticket:2646 at ​https://github.com/buildbot/trac2gh/issues/3

markdown conversion somehow works only partially (or i imagined that markdown allows for one-sentence-per-line)

[sa2ajj]

Updated the format (target, please comment) at ​https://github.com/buildbot/trac2gh/issues/3#issuecomment-257339035