Trac to Phabricator (Maniphest) migration prototype
matthewtpickering at gmail.com
Wed Dec 21 13:59:20 UTC 2016
> Is it possible for those like me who have a different username on trac and
> phabricator to get mapped correctly?
Yes, definitely. I would need to work out exactly what to do about
user accounts, for this I just created accounts with the same names.
There are two things to consider about a more intelligent mapping.
1. People who have different names on each site.
2. People who don't have phab accounts but do have trac accounts.
> And how does the ticket creation process look? I tried it but needed to
> login. Do you get a set of projects you have to pick? Like the custom fields
> we have now or is it just one box where you have to add stuff to all in one
I sent you some login details so you can try it out.
> Kind regards,
> On Wed, 21 Dec 2016, 10:13 Matthew Pickering, <matthewtpickering at gmail.com>
>> Dear devs,
>> I have completed writing a migration which moves tickets from trac to
>> phabricator. The conversion is essentially lossless. The trac
>> transaction history is replayed which means all events are transferred
>> with their original authors and timestamps. I welcome comments on the
>> work I have done so far, especially bugs as I have definitely not
>> looked at all 12000 tickets.
>> All the user accounts are automatically generated. If you want to see
>> the tracker from your perspective then send me an email or ping me on
>> IRC and I can set the password of the relevant account.
>> NOTE: This is not a decision, the existence of this prototype is to
>> show that the migration is feasible in a satisfactory way and to
>> remove hypothetical arguments from the discussion.
>> I must also thank Dan Palmer and Herbert who helped me along the way.
>> Dan was responsible for the first implementation and setting up much
>> of the infrastructure at the Haskell Exchange hackathon in October. We
>> extensively used the API bindings which Herbert had been working on.
>> Further information below!
>> Why this change? The main argument is consolidation. Having many
>> different services is confusing for new and old contributors.
>> Phabricator has proved effective as a code review tool. It is modern
>> and actively developed with a powerful feature set which we currently
>> only use a small fraction of.
>> Trac is showing signs of its age. It is old and slow, users regularly
>> lose comments through accidently refreshing their browser. Further to
>> this, the integration with other services is quite poor. Commits do
>> not close tickets which mention them and the only link to commits is a
>> comment. Querying the tickets is also quite difficult, I usually
>> resort to using google search or my emails to find the relevant
>> Why is Phabricator better?
>> Through learning more about Phabricator, there are many small things
>> that I think it does better which will improve the usability of the
>> issue tracker. I will list a few but I urge you to try it out.
>> * Commits which mention ticket numbers are currently posted as trac
>> comments. There is better integration in phabricator as linking to
>> commits has first-class support.
>> * Links with differentials are also more direct than the current
>> custom field which means you must update two places when posting a
>> * Fields are verified so that mispelling user names is not possible
>> (see #12623 where Ben mispelled his name for example)
>> * This is also true for projects and other fields. Inspecting these
>> fields on trac you will find that the formatting on each ticket is
>> often quite different.
>> * Keywords are much more useful as the set of used keywords is
>> * Related tickets are much more substantial as the status of related
>> tickets is reflected to parent ticket.
>> Keywords are implemented as projects. A project is a combination of a
>> tag which can be used with any Phabricator object, a workboard to
>> organise tasks and a group of people who care about the topic. Not all
>> keywords are migrated. Only keywords with at least 5 tickets were
>> added to avoid lots of useless projects. The state of keywords is
>> still a bit unsatisfactory but I wanted to take this chance to clean
>> them up.
>> Custom fields such as architecture and OS are replaced by *projects*
>> just like keywords. This has the same advantage as other projects.
>> Users can be subscribed to projects and receive emails when new
>> tickets are tagged with a project. The large majority of tickets have
>> very little additional metadata set. I also implemented these as
>> custom fields but found the the result to be less satisfactory.
>> Some users who have trac accounts do not have phab accounts.
>> Fortunately it is easy to create new user accounts for these users
>> which have empty passwords which can be recovered by the appropriate
>> email address. This means tickets can be properly attributed in the
>> The ticket numbers are maintained. I still advocate moving the
>> infrastructure tickets in order to maintain this mapping. Especially
>> as there has been little activity in thr the last year.
>> Tickets are linked to the relevant commits, differentials and other
>> tickets. There are 3000 dummy differentials which are used to test
>> that the linking works correctly. Of course with real data, the proper
>> differential would be
>> There are a couple of issues currently with the migration. There are a
>> few issues in the parser which converts trac markup to remarkup. Most
>> comments have very simple with just paragraphs and code blocks but
>> complex items like lists are sometimes parsed incorrectly. Definition
>> lists are converted to tables as there are no equivalent in remarkup.
>> Trac ticket links are converted to phab ticket links.
>> The ideal time to migrate is before the end of January The busiest
>> time for the issue tracker is before and after a new major release.
>> With 8.2 planned for around April this gives the transition a few
>> months to settle. We can close the trac issue tracker and continue to
>> serve it or preferably redirect users to the new ticket. I don't plan
>> to migrate the wiki at this stage as I do not feel that the parser is
>> robust enough although there are now few other technical challenges
>> blocking this direction.
>> ghc-devs mailing list
>> ghc-devs at haskell.org
More information about the ghc-devs