Trac to Phabricator (Maniphest) migration prototype

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
tickets.

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
much.

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 -
http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/advanced/
Using this you can sort by priority and then by ticket number. Here is
an example searching the tickets with the PatternSynonyms tag -
http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/WjCq6bD27idM/#R

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
trend.

Thanks for your comments.

Matt

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:
>
>     http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T8095
>     https://ghc.haskell.org/trac/ghc/ticket/8095
>
>    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?