Trac to Phabricator (Maniphest) migration prototype

Thu Jan 5 01:34:40 UTC 2017

In response to no# 2, I was looking at this my self since I think separate
fields would definitely be useful. It seems you can customize the form
design on phabricrator.

I think it would definitely be worth it to make a new form layout
resembling the layout of track. I don't know how it stores it but
presumably this would also improve the searching allowing you to filter on
specific fields instead of just tags.

Have you looked into this already Matt?

On Tue, 3 Jan 2017, 23:33 Matthew Pickering, <matthewtpickering at gmail.com>
wrote:

> 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?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170105/68de102a/attachment.html>