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/ad... 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/Wj... 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 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?

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

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

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

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, 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/ad... 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/Wj...

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Jan 8, 2017, at 12:40 AM, Ben Gamari wrote:

* Metadata: Custom fields are supported.

In agreement with your comments above, I'm glad to see this. Trac's metadata currently is suboptimal, but I don't think this means we should throw out the ability to have structured metadata in its entirety.

* Flexible user interface: Custom fields can be hidden from the new ticket form to prevent user confusion.

Yay.

* Familiarity: Many users may feel more at home in Phabricator's interface; reMarkup's similarity to Markdown also helps.

Nitpick: Do we have any control over this? (I doubt it.) I find switching between GitHub Markdown, RST, and reMarkup to be a low-grade but constant annoyance.

* Legibility:

I seem to recall that Phab originally used gray-on-white in Diffs, but we were able to fix with some CSS. (Or did it require upstream intervention?) Perhaps we can do something similar here. I find the modern trend to use lower-contrast interfaces utterly maddening.

What does Trac do well? -----------------------

* Convenient cross-referencing: while the syntax is a bit odd, once you acclimate it is quite liberating to be able to precisely cross-reference tickets, wiki documents, and comments without copying links around.

Yesyesyes.

* Automation of ticket lifecycle: Trac tickets progress through their lifecycle (e.g. from "new" to "patch" to "merge" to "closed" statuses) through predefined actions. This means that moving a ticket through its lifecycle typically only requires one click and the right thing happens with no additional effort. I think this is a great model, although in practice it's not clear how much we benefit from it compared to a typical Maniphest workflow.

I'm less convinced about this benefit of Trac. For instance, if I close a ticket in error, I lose ownership. Then I have to reopen but cannot set an owner at the same time. Maybe it's just a configuration issue, but I imagine we have experienced devs doing ticket-state management and don't need strict controls here.

What does Trac do poorly? -------------------------

* Active development: Trac is largely a stagnant project.

I was unaware of this. This is a significant downside in my opinion.

* Safety: I have personally lost probably a half-dozen hours of my life to Trac eating comments.

That's odd. I have not had this experience.

* Relations between tickets: Trac has essentially no first-class notion of ticket relatedness. Even duplicate tickets need to be manually annotated in both directions.

Yes. Frustrating.

* Keywords are hard to discover and apply

Yes. With discoverable keywords, we might be able to get more reporter buy-in. One more issue that we should consider: email notification. Perhaps I'm stodgy, but I'm a big fan of email. Trac emails notifications are not quite ideal (I wish the new content came above the metadata), but they're very functional. How does Phab compare? Can we see a sample notification it might create? Thanks! Richard

On Jan 9, 2017, at 6:41 AM, Matthew Pickering wrote:

Component -> Projects OS -> (Sub)Projects Arch -> (Sub)Projects

What is a (Sub)Project? I've been operating under the assumption that a Project is just a tag. Do these tags have structure? My best guess from your discussion is that when you choose on Project, you are then forced to choose one of a set of others. That seems like a good plan.

Keywords -> Projects Version -> Remove (It is a proxy for date reported)

No no no no. I don't think either of us will convince the other on this point, but we should be clear that we need input from others to decide on this one.

Milestone -> Project (Milestone)

What does this mean? What is "Project (Milestone)"?

I have some example emails. https://phabricator.haskell.org/M2

Looks good. Thanks for posting this! Richard

On this Phab question, does Phab have an equivalent to Trac's wiki? That's quite important. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Matthew | Pickering | Sent: 10 January 2017 11:59 | To: Richard Eisenberg | Cc: GHC developers | Subject: Re: Trac to Phabricator (Maniphest) migration prototype | | Subprojects and Milestones are both special kinds of projects. | | Subprojects are like projects but are associated with a parent project. | Unfortunately this doesn't really show up anywhere on the UI. | There is quite a long discussion about this on the upstream issue tracker - | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.phab | ricator.com%2FT10349&data=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb843 | 78ec2a08d439502937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840 | 067524&sdata=7KEVArFhp3bIBclu2Drh8hSn8d47Q1aXrhGRQVKp%2BwM%3D&reserved=0 | | Milestones are projects which are meant for tracking releases. A project can | only have one milestone at a time and importantly the parent project is | shown on the UI with milestones. | | I took some screenshots to show how they show up in UI. | | https://phabricator.haskell.org/M3 | | If you're interested about projects then the best place to read is | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure.phab | ricator.com%2Fbook%2Fphabricator%2Farticle%2Fprojects%2F&data=02%7C01%7Csimo | npj%40microsoft.com%7Cfe21d0babfb84378ec2a08d439502937%7C72f988bf86f141af91a | b2d7cd011db47%7C1%7C0%7C636196463840067524&sdata=MfqbX%2BCzMtqf4wIRhe0MUqSN4 | l8l7oRiDO3IUIqb8ag%3D&reserved=0 | | They are not very mature and I expect their usage will be refined in the | next iteration. The UI for selecting projects could certainly be improved | rather than presenting a list of amorphous labels. | | Matt | | On Mon, Jan 9, 2017 at 6:41 PM, Richard Eisenberg | wrote: | > | >> On Jan 9, 2017, at 6:41 AM, Matthew Pickering | wrote: | >> | >> Component -> Projects | >> OS -> (Sub)Projects | >> Arch -> (Sub)Projects | > | > What is a (Sub)Project? I've been operating under the assumption that a | Project is just a tag. Do these tags have structure? My best guess from your | discussion is that when you choose on Project, you are then forced to choose | one of a set of others. That seems like a good plan. | > | >> Keywords -> Projects | >> Version -> Remove (It is a proxy for date reported) | > | > No no no no. I don't think either of us will convince the other on this | point, but we should be clear that we need input from others to decide on | this one. | > | >> Milestone -> Project (Milestone) | > | > What does this mean? What is "Project (Milestone)"? | > | >> I have some example emails. https://phabricator.haskell.org/M2 | > | > Looks good. Thanks for posting this! | > | > Richard | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell | .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb84378ec2a08d4395029 | 37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840067524&sdata=mRz | Phhzd1Xjqfbwz%2BTtfESWg4gbdSWx5gC2HpDUtSuM%3D&reserved=0

With regards to the other two points that Ben made. I solicited the opinion of a few people when I first made the prototype and the reaction was that it didn't matter to them. We should really make this decision based on the opinions of people who are high utilisers of the tracker. The experience should be better for occasional contributors as there are many more options for authentication and clearer control over notifications. The interaction with the stable branch was something I had not considered yet so thank you for bringing this up. I spent yesterday looking at the situation and it doesn't look like there is anything immediate which could help with release management. People in #phabricator told me that we shouldn't use Releeph as there were plans to change it significantly and it wasn't a finished product. They pointed me to https://secure.phabricator.com/T9530 and https://secure.phabricator.com/D16981 which describe the future of the feature. In particular, the "Facebook-Style Cherry-Picks / Phabricator-Style Stable / Backporting" work flow looks close to current practices. This being said, it isn't clear at all when they plan to introduce these features. Custom forms are also a good idea. We could even modify the URLs sometimes produced by the compiler for panics to prefill certain fields of the form. (For example.. http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/maniphest/task/edit/?projects=Inlining&title=Simplified%20Ticks%20Exhausted) Matt On Sun, Jan 8, 2017 at 5:40 AM, Ben Gamari wrote:

Matthew Pickering writes:

...

Dear devs,

Hi Matthew and Dan,

First, thanks for your work on this; it is an impressive effort. Reconstructing a decade of tickets with broken markup, tricky syntax, and a strange data model is no easy task. Good work so far!

On the whole I am pleasantly surprised by how nicely Maniphest seems to hang together. I have pasted my notes from my own reflection on the pros and cons of both systems below. On re-reading them, it seems clear that Trac does leave us with a number of issues which Phabricator may resolve.

As I've expressed in the past, I think we should consider preservation of ticket numbers to be an absolute requirement of any migration. To do otherwise imposes a small cost on a large number of people for a very long time with little benefit. GHC infrastructure exists to support GHC, not the other way around.

However, ticket numbers notwithstanding I think I would be fine moving in this direction if the community agrees that this is the direction we want to go in.

There are a few questions that remain outstanding, however:

What do others think of this? =============================

Does Phabricator address the concerns that others, including those outside of the usual GHC development community, have raised about our issue tracking in the past? It would be interesting to hear some outside voices.

How do we handle the stable branch? ===================================

One important role that the issue tracker plays is ensuring that patches are backported to the stable branch when appropriate. In Trac we handle this with a "merge" state (indicating that the ticket has been fixed in `master`, but the fix needs to be backported) and the milestone field (to indicate which release we want to backport to).

A significant amount of GHC's maintenance load is spent backporting and updating tickets, so it's important that this process works smoothly and reliably. I think this is may be an area where Phabricator could improve the status quo since the workflow currently looks something like this,

1. Someone merges a patch to `master` fixing an issue; if the commit message mentions the ticket number then our infrastructure automatically leaves a comment referencing the commit on the ticket.

2. Someone (usually the committer) places the ticket in `merge` state and sets the milestone appropriately

3. I merge the patch to the stable branch

4. I close the ticket and manually leave a comment mentioning the SHA of the backported commit.

In particular (4) is more work than it needs to be; ideally comment generation would be automated as it is for commits to `master` but Trac's comment-on-commit functionality is a bit limited, so this is currently not an option.

I'm not sure what Phabricator's analogous workflow to the above might look like. It seems that Phabricator's Releeph module may be in part intended for this use-case, but it seems to have some unfortunate limitations (e.g. the inflexibility in branch naming) that make it hard to imagine it being usable in our case.

Setting aside Releeph, perhaps the best solution would be to continue with our current workflow: we would retain the "status" state and milestone projects would take the place of the current "milestone" field. If I'm not mistaken Phabricator can be configured to mention commits on stable branches in the ticket history, so this should help point (4).

Which fields should be preserved? =================================

Our Trac instance associates a lot of structured metadata with each ticket. I generally think that this is a good thing, especially compared to the everything-is-a-tag model which I have found can quickly become unmaintainable. Unfortunately, Trac makes our users pay for these fields with a confusing ticket form.

It appears that Phabricator's Transactions [1] module may allow us to have our cake and eat it too: we can define one form for users to create tickets and another, more complete form for developer use. In light of this I don't see why we would need to fall back to the everything-is-a-tag. Matthew, what did you feel was less-than-satisfactory about the proper-fields approach? I fear that relevant metadata like GHC version, operating system and architecture simply won't be provided unless the user is explicitly prompted; I personally find the cue to be quite helpful. Presumably contributors can set Herald rules for notification on these fields if they so desire.

In the particular case of the "Component" field, I personally try to set this correctly when possible and have certainly found it useful as a search criterion. However, I suspect it would be fine as a tag. I also know that Simon PJ is quite fond of the test case field (although few others as as diligent in keeping this one up to date).

How would we migrate and what will become of Trac? ==================================================

The mechanics of migration will take time and effort to work out. If we decide this is the right direction I think we should be cautious in setting timelines; we should take as much time as we need to do it correctly. Regardless, we should gather a consensus on the general direction before we start hashing this out.

Thanks again for your effort on this, Matthew and Dan, and sorry it took me so long to finally get these notes out.

Cheers,

- Ben

[1] https://secure.phabricator.com/book/phabricator/article/forms/

Notes =====

These were largely for my sake to keep track of the pros and cons of the two options. I've nevertheless included them here for completeness.

What does Maniphest do well? ----------------------------

* Actively developed: Phabricator will continue to improve in the future.

* Metadata: Custom fields are supported.

* Flexible user interface: Custom fields can be hidden from the new ticket form to prevent user confusion.

* Familiarity: Many users may feel more at home in Phabricator's interface; reMarkup's similarity to Markdown also helps.

* Integration: Having Phabricator handle code review, release management, and issue tracking will hopefully reduce maintenance workload.

* Notifications: Herald's rule-based notifications are quite handy.

What does Maniphest do poorly? ------------------------------

* Flexibility of search: The search options feel a bit more limiting than Trac; in particular the ability to show arbitrary columns in search results seems conspicuously missing.

* Legibility: This is admittedly to some extent a matter of aesthetics but the search results list feels very busy and is quite difficult to quickly scan. This is made exacerbated by the fact that some aspects of the the color scheme are quite low contrast (e.g. grey against white for closed tickets). This hurts quite a bit since a number of contributors spend a significant amount of time looking through lists of tickets. Perhaps we could convince the Phacility people to provide a more legible, compact presentation option.

What does Trac do well? -----------------------

* Convenient cross-referencing: while the syntax is a bit odd, once you acclimate it is quite liberating to be able to precisely cross-reference tickets, wiki documents, and comments without copying links around.

* Automation of ticket lifecycle: Trac tickets progress through their lifecycle (e.g. from "new" to "patch" to "merge" to "closed" statuses) through predefined actions. This means that moving a ticket through its lifecycle typically only requires one click and the right thing happens with no additional effort. I think this is a great model, although in practice it's not clear how much we benefit from it compared to a typical Maniphest workflow.

* Rich metadata: Tickets can have a variety of metadata fields which can be queried in sophisticated ways .

What does Trac do poorly? -------------------------

* Familiarity: Many users feel rather lost in Trac

* Active development: Trac is largely a stagnant project.

* Spam management: Keeping spam at bay has been a challenge. We seem to have it under control at the moment, but I wonder how long this will last for.

* Safety: I have personally lost probably a half-dozen hours of my life to Trac eating comments.

* Integration with code review workflow: We use Phabricator for CI and code review; the only thing that remains on Trac are our tickets and the Wiki. Keeping these two resources in sync is time-consuming and error-prone.

* Full text search: Trac's full text search capabilities are generally terrible. While I've tried working around this using PostgreSQL's native full text search functionality, the result is poorly integrated into Trac and consequently hard to use.

* Customizability of the ticket form: While the rich metadata that Trac supports can be very helpful developers, it can also be confusing to users. Ideally we would hide these fields but Trac does not give us the ability to do so.

* Relations between tickets: Trac has essentially no first-class notion of ticket relatedness. Even duplicate tickets need to be manually annotated in both directions.

* Keywords are hard to discover and apply

* Fine-grained notification support is nearly non-existent

I experimented a bit more with subprojects and I was able to add a +6 line patch to make them behave a bit better. Specifically, the parent project now appears in the UI and auto complete works as expected. https://phabricator.haskell.org/M3/6/ Matt On Tue, Jan 10, 2017 at 6:51 PM, Ben Gamari wrote:

Matthew Pickering writes:

...

Dear devs,

I have completed writing a migration which moves tickets from trac to phabricator. The conversion is essentially lossless. The trac transaction history is replayed which means all events are transferred with their original authors and timestamps. I welcome comments on the work I have done so far, especially bugs as I have definitely not looked at all 12000 tickets.

We discussed this a bit in this week's GHC call and the general feeling was that it would be nice to have a comprehensive list of the pros and cons somewhere. I pasted my notes on the Wiki [1] as a starting point.

Matthew, would you like to add your thoughts there as well?

Cheers,

- Ben

[1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Maniphest