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