Opened 12 months ago

Last modified 9 months ago

#3623 assigned task

moving trac tickets to GitHub

Reported by: sa2ajj Owned by: sa2ajj
Priority: major Milestone: sys - on-bb-infra
Version: Keywords:
Cc:

Description (last modified by tardyp)

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

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.

Change History (29)

comment:1 Changed 12 months ago by 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)

comment:2 Changed 12 months ago by sa2ajj

  • Description modified (diff)

comment:3 Changed 12 months ago by 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

comment:4 Changed 11 months ago by sa2ajj

  • Description modified (diff)

description is updated with field information

comment:5 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:6 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:7 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:8 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:9 Changed 11 months ago by 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!

comment:10 Changed 11 months ago by 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."

Last edited 11 months ago by sa2ajj (previous) (diff)

comment:11 Changed 11 months ago by 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 :))

comment:12 Changed 11 months ago by 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.

comment:13 Changed 11 months ago by sa2ajj

  • Description modified (diff)
  • Owner set to sa2ajj
  • Status changed from new to assigned

comment:14 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:15 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:16 Changed 11 months ago by 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?..

comment:17 Changed 11 months ago by sa2ajj

  • Description modified (diff)

User searches are possible

comment:18 Changed 11 months ago by sa2ajj

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

comment:19 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:20 Changed 11 months ago by sa2ajj

  • Description modified (diff)

comment:21 Changed 11 months ago by sa2ajj

current count -- 100 tickets

comment:22 Changed 11 months ago by sa2ajj

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

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

comment:23 Changed 11 months ago by sa2ajj

looks like the above milestones result in 35 tickets

comment:24 Changed 11 months ago by 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)

comment:25 Changed 11 months ago by sa2ajj

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

comment:26 Changed 11 months ago by tardyp

  • Description modified (diff)

comment:27 Changed 11 months ago by dustin

@sa2ajj, any update here? Based on the ticket summary, it looks like things are largely ready to roll. Regarding the open questions:

  • wiki links -> keep the links to BB trac? -- sounds good
  • formatting? try to convert to Markdown? render HTML and use it as is? -- html is a subset of markdown, so that seems like the most likely to come out OK
  • ticket history -> copy in the second comment? -- aside from ticket comments, I don't think we need this
  • attachments -> GH does not have the feature -- these are occasionally useful, but *very* useful in those cases. We didn't bring attachments over when porting from SourceForge to Trac, and I've missed them. Could we upload them to a github repo and link to them?

comment:28 Changed 10 months ago by sa2ajj

comments need to be taken into account as well!

comment:29 Changed 9 months ago by dustin

@sa2ajj, what do you think?

I think we should not let the perfect be the enemy of the good here -- a simple transition with links back to the original content will suffice for most purposes, and I expect we'll get a good crop of new, better bugs in Github once the transition is made.

Note: See TracTickets for help on using tickets.