Trac to Phabricator (Maniphest) migration prototype

Wed Jan 4 10:20:51 UTC 2017

I should have looked more closely at the implementation.. the
component field was already preserved. There is a bug where it is not
set properly if it was set by the ticket reporter. I will look into
this problem this evening!

Matt

On Wed, Jan 4, 2017 at 10:18 AM, Matthew Pickering
<matthewtpickering at gmail.com> wrote:
> I am persuaded that component is useful. Richard makes the point that
> there is a murky divide between component and keywords. This is right
> and it indicates that we should keep the component field but also
> homogenise it was the keywords (in the form of projects).
>
> I have included which fields are used frequently in the footer of this message.
>
> The arguments for version are not convincing. The first thing you do
> when working on a ticket anyway is to try and reproduce the bug with a
> test case in HEAD. The date a ticket reported is as good an indicator
> of version.
>
> I also noted that I neglected to update the dateUpdated field for
> tickets so queries by date last modified do not currently work and
> some dates may appear strange when searching.
>
> Edward: There is support for bucketing by project as well. See this
> query for example,
> http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/query/AnBbna53Q.ue/#R
>
> In these discussions we should remember that phabricator is not trac.
> I am not trying to exactly recreate the trac experience because
> otherwise we might as well carry on using trac.
>
> Matt
>
>         newvalue         | count |       data last used
>
> -------------------------+-------+------------------
>  Core Libraries          |   171 | 1467895032829170
>  Compiler (Type checker) |   162 | 1473084454218219
>  Runtime System          |   128 | 1465462467207643
>  GHCi                    |    78 | 1469178319691539
>  Build System            |    67 | 1466005572342115
>  libraries/base          |    63 | 1434353266824396
>  Template Haskell        |    60 | 1471813543330680
>  Compiler                |    57 | 1454111515909737
>  Compiler (Parser)       |    48 | 1469089960346131
>  libraries (other)       |    43 | 1426680041417003
>  Documentation           |    34 | 1469109265405752
>  Runtime System (Linker) |    31 | 1465457535216398
>  Profiling               |    27 | 1464370392337006
>  Compiler (NCG)          |    24 | 1464454221111344
>  Driver                  |    23 | 1464988993920936
>  Compiler (Linking)      |    20 | 1453415934718049
>  Package system          |    19 | 1445379269305504
>  Test Suite              |    19 | 1466101320438273
>  libraries/process       |    17 | 1380279285602376
>  Compiler (LLVM)         |    17 | 1453643706521552
>  Trac & Git              |    13 | 1417192612294646
>  Compiler (CodeGen)      |    12 | 1466888486602141
>  Code Coverage           |     9 | 1463929919796252
>  Compiler (FFI)          |     9 | 1438109440242842
>  libraries/unix          |     8 | 1393611940333801
>  Data Parallel Haskell   |     8 | 1427089471985001
>  None                    |     8 | 1457637409612864
>  hsc2hs                  |     5 | 1433929228414856
>  libraries/network       |     5 | 1225140383000000
>  libraries/random        |     4 | 1404824781090514
>  libraries/directory     |     4 | 1355926496000000
>  External Core           |     4 | 1365855698000000
>  libraries/pretty        |     4 | 1321743759000000
>  ghc-pkg                 |     4 | 1447954686599857
>  GHC API                 |     3 | 1463577929270933
>  libraries/HGL           |     3 | 1214961444000000
>  Prelude                 |     2 | 1313617037000000
>  libraries/haskell98     |     1 | 1186695581000000
>  libraries (old-time)    |     1 | 1215426256000000
>  Visual Haskell          |     1 | 1166430307000000
>  NoFib benchmark suite   |     1 | 1405260335339305
>
> On Wed, Jan 4, 2017 at 4:34 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
>> 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?