Trac to Phabricator (Maniphest) migration prototype

Wed Jan 4 10:18:16 UTC 2017

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?