Trac to Phabricator (Maniphest) migration prototype

[Edward Z. Yang]

Excerpts from Matthew Pickering's message of 2017-01-03 23:32:42 +0000:
> 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.

Echoing Richard's comment, it's a helpful reminder to the reporter
to say what version of GHC the bug was on.  If it's old, the first
thing to do is check if it still fails in HEAD.

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

I think that there is a substantial subset of tickets that have a good
"component" characterization.  I have historically found "Runtime
system", "Linker", "Build system", "Profiling" and a number of others
very useful.  Yes, a lot of tickets get dumped in "Compiler", but many
have very good categorization!

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

I am a "regular user" of Cabal's GitHub bug tracker, and I find it
difficult to remember to apply all of the tags that I'm "supposed" to
for any given ticket.  It got better when I reorged all the tags
to give them a prefix for the "category" they were in, but I still
have to scroll through the list that contains ALL THE TAGS when
really I just want to select one per category.  For example, priority
in GH is a complete lost cause because none of the display mechanisms
take priority into account.

Another benefit of tags by category is in tabular views, you can ask
to group things by category, or priority, etc.  Tag based systems rarely
have this kind of UI.

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

Well, this is something we can fix with a little CSS :)

Edward

> 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?