Trac to Phabricator (Maniphest) migration prototype
matthewtpickering at gmail.com
Tue Jan 3 23:32:42 UTC 2017
Good comments Edward. I think the answers to all three of your points
will be insightful.
1. As for why it appears some information from the ticket is missing.
The version field is not very useful as there are only two active
branches at once. Instead we want a project which marks tickets which
apply to the 8.0.2 branch for example. Tickets which refer to ancient
versions of GHC should be closed if they can't be reproduced with
HEAD. It is also not used very often, only updated on about 600
A tag for the architecture field is only added if the architecture is
set to something other than the default. The ticket you linked had the
default value and in fact, architecture was irrelevant to the ticket
as it was about the type checker so it could be argued including this
option is confusing to the reporter.
I'm also skeptical about how useful the component field is. I've never
personally used it and it is not accurate for the majority of tickets.
If someone disagrees then please say but it is really not used very
Finally, the related tickets look slightly off.
This is a reoccurring problem with trac, there is no validation for
any of the text fields. The parser I wrote assumed that tickets
started with a # but in this example the first related ticket
initially was hashless. There are many examples like this which I have
come across. In this case I think I can relax it to search for any
contiguous set of numbers and recover the correct information.
The dump of the database which I had is about two months old which
explains why the most recent changes are not included.
Here is how often each field has been updated.
field | count
_comment0 | 1839
_comment1 | 364
_comment10 | 1
_comment11 | 1
_comment12 | 1
_comment13 | 1
_comment14 | 1
_comment15 | 1
_comment16 | 1
_comment2 | 123
_comment3 | 53
_comment4 | 23
_comment5 | 13
_comment6 | 4
_comment7 | 4
_comment8 | 3
_comment9 | 1
architecture | 2025
blockedby | 1103
blocking | 1112
cc | 5358
comment | 75967
component | 1217
description | 1919
differential | 2410
difficulty | 4968
failure | 1427
keywords | 833
milestone | 13695
os | 1964
owner | 4870
patch | 26
priority | 2495
related | 1869
reporter | 7
resolution | 10446
severity | 83
status | 14612
summary | 827
testcase | 2386
type | 811
version | 687
wikipage | 873
2. This is a legitimate point. I will say in response that the
majority of triaging is done by those who regularly use the bug
tracker. These people will know the correct tags to use. There are
occasionally people who submit tickets and ask questions about what to
fill in these fields or fill them in incorrectly. Removing them for a
uniform system is advantageous in my opinion.
3. Here is how the search works. It is context sensitive, if you
search from the home page then you search everything. If you search
after clicking on "maniphest" to enter the maniphest application it
will only search tickets.
There is a similar advanced search for Maniphest -
Using this you can sort by priority and then by ticket number. Here is
an example searching the tickets with the PatternSynonyms tag -
I agree with you about the default layout. I would also like a more
compact view but I feel this style is the prevailing modern web dev
Thanks for your comments.
On Tue, Jan 3, 2017 at 5:21 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Hi Matthew,
> Thanks for doing the work for setting up this prototype, it definitely
> helps in making an informed decision about the switch.
> Some comments:
> 1. In your original email, you stated that many of the custom fields
> were going to be replaced with Phabricator "projects" (their
> equivalent of tags). First, I noticed a little trouble where
> some fields were just completely lost. Compare:
> AFAICT, we lost version the bug was found in,
> architecture, component. I hope we can keep these details
> in the real migration! Also related tickets doesn't seem
> to be working (see example above); migration problem?
More information about the ghc-devs