Thank you Simon. If you have any example queries that you run often or queries which you have embedded into wikipages then it would be useful to share them so I can investigate. With regards to the last point. This is possible in a more structured way. You can create a dashboard with a single query embedded and then embed this using standard remarkup syntax. For example on a project page, I embedded a query which matched tickets with "PatternSynonyms" and "newcomer". http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/project/profile/16... You can embed this panel anywhere where remarkup is accepted. For example, in a wiki page - http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/w/ or tickets http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T12548 It is a bit more heavyweight to setup but much easier to get right due to the structured editing interface which trac doesn't provide for these kinds of queries. Matt On Tue, Jan 24, 2017 at 9:41 AM, Simon Marlow wrote:

On 21 January 2017 at 22:21, Matthew Pickering wrote:

...

Hello devs,

Thanks to everyone so far who has looked at and commented on the prototype. It seems that the response is generally positive so I would like to drive the process forwards.

In order for that to happen, someone needs to decide whether we as a community think it is a good idea. It seems to make sense if those who use the tracker most make this decision so I propose that Simon and Ben should ultimately be the ones to do this.

Therefore, I propose this timeline

1. Before 11th Feb (3 weeks from today) we decide whether we want to migrate the issue tracker. 2. A working group is established who will work through the details of the migration with the minimum of a final prototype built from a clone of the actual installation. 3. Migration would happen before the end of March.

Sounds good to me. I personally have only glanced at it so far, but I'll give it some attention. I'm pretty attached to Trac's ability to do complex queries on tickets and the ability to embed ticket queries into wiki pages, so the gains would have to be compelling to outweigh the losses for me. But I'll give it a closer look.

Cheers Simon

...

I think Ben summarised the discussions quite well on the wiki page - https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Maniphest

And the prototype continues to exist here. http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/

As always, any comments welcome.

Matt _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Tue, Jan 24, 2017 at 1:26 PM, Simon Marlow wrote:

On 24 January 2017 at 10:37, Matthew Pickering wrote:

...

Thank you Simon.

If you have any example queries that you run often or queries which you have embedded into wikipages then it would be useful to share them so I can investigate.

The 8.2.1 status page has queries embedded: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1

Personally I do queries like "all open bugs where Component = RuntimeSystem ordered by priority". It looks like we can probably do that with Maniphest.

I couldn't take a look at the interface for creating a ticket because I have to create an account, and it says my account is pending approval.

Does Maniphest have a concept of ticket dependencies? i.e. ticket X is blocked by Y.

Yes, see for example - http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T7724

Can we have custom fields with Maniphest? I like the rich metadata we have with OS / Architecture / Component / Failure types. It's true that we don't use it consistently, but at least when we do use it there's an obvious and standard way to do it. When I search for RTS bugs I know that at least all the bugs I'm seeing are RTS bugs, even if I'm not seeing all the RTS bugs. People responsible for particular architectures can keep their metadata up to date to make it easier to manage their ticket lists.

There was a long discussion about this on the original thread with people echoing this sentiment. I am of the opinion that projects would be a better fit as 1. They integrate better with the rest of phabricator 2. They are not relevant to every ticket. There are tickets about infrastructure matters for which the concept of OS is irrelevant for example. I like to think of projects as structured unstructured metadata. The structure is that you can group different project tags together as subprojects of a parent project but adding projects to a ticket is unstructured. This is how "architecture" is implemented currently - http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/project/view/101/ On trac, keywords are not very useful as they are completely unstructured and not discoverable. I think projects greatly improve on this. I also posted some images about the different work flows of projects, subprojects and custom fields. https://phabricator.haskell.org/M3/3/ http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/M1

...

With regards to the last point. This is possible in a more structured way. You can create a dashboard with a single query embedded and then embed this using standard remarkup syntax.

For example on a project page, I embedded a query which matched tickets with "PatternSynonyms" and "newcomer".

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/project/profile/16...

You can embed this panel anywhere where remarkup is accepted. For example, in a wiki page - http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/w/ or tickets http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T12548

Ok, it's good to know that Phabricator can embed queries, but we're not planning to move the wiki, correct?

I am not proposing that but if there is interest it could be investigated. The migration would be trickier due to the complicated ways that people use markup in wiki pages.

...

It is a bit more heavyweight to setup but much easier to get right due to the structured editing interface which trac doesn't provide for these kinds of queries.

Matt

On Tue, Jan 24, 2017 at 9:41 AM, Simon Marlow wrote:

...

On 21 January 2017 at 22:21, Matthew Pickering wrote:

...

Hello devs,

Thanks to everyone so far who has looked at and commented on the prototype. It seems that the response is generally positive so I would like to drive the process forwards.

In order for that to happen, someone needs to decide whether we as a community think it is a good idea. It seems to make sense if those who use the tracker most make this decision so I propose that Simon and Ben should ultimately be the ones to do this.

Therefore, I propose this timeline

1. Before 11th Feb (3 weeks from today) we decide whether we want to migrate the issue tracker. 2. A working group is established who will work through the details of the migration with the minimum of a final prototype built from a clone of the actual installation. 3. Migration would happen before the end of March.

Sounds good to me. I personally have only glanced at it so far, but I'll give it some attention. I'm pretty attached to Trac's ability to do complex queries on tickets and the ability to embed ticket queries into wiki pages, so the gains would have to be compelling to outweigh the losses for me. But I'll give it a closer look.

Cheers Simon

...

I think Ben summarised the discussions quite well on the wiki page - https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Maniphest

And the prototype continues to exist here. http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/

As always, any comments welcome.

Matt _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hope that is useful. Matt

I discovered today that it is now possible to create custom dashboards for a project and make it the default view. This could be useful for projects which have a lot of associated queries or we want some more fine grained control about how the page looks. Matt On Tue, Jan 24, 2017 at 6:12 PM, Simon Marlow wrote:

On 24 January 2017 at 14:09, Matthew Pickering wrote:

...

On Tue, Jan 24, 2017 at 1:26 PM, Simon Marlow wrote:

...

Can we have custom fields with Maniphest? I like the rich metadata we have with OS / Architecture / Component / Failure types. It's true that we don't use it consistently, but at least when we do use it there's an obvious and standard way to do it. When I search for RTS bugs I know that at least all the bugs I'm seeing are RTS bugs, even if I'm not seeing all the RTS bugs. People responsible for particular architectures can keep their metadata up to date to make it easier to manage their ticket lists.

There was a long discussion about this on the original thread with people echoing this sentiment. I am of the opinion that projects would be a better fit as

1. They integrate better with the rest of phabricator 2. They are not relevant to every ticket. There are tickets about infrastructure matters for which the concept of OS is irrelevant for example.

I like to think of projects as structured unstructured metadata. The structure is that you can group different project tags together as subprojects of a parent project but adding projects to a ticket is unstructured. This is how "architecture" is implemented currently -

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/project/view/101/ On trac, keywords are not very useful as they are completely unstructured and not discoverable. I think projects greatly improve on this.

I think the problem here is that it's not obvious which projects should be added to tickets. As a ticket submitter, if I have metadata I'm not likely to add it, and as developers we'll probably forget which fields we could add.

Yes, Trac keywords are even more useless. But we don't generally use keywords; the point here is about the other metadata fields (OS, Architecture, etc.). Just having some text on the ticket creation page to suggest adding OS / Architecture would help a lot.

Cheers Simon

Thinking about this, it would probably make sense to at least transfer the newcomer page as most of its instructions would reference things on phab rather than trac if we migrated the tracker. On Tue, Jan 24, 2017 at 4:00 PM, Joachim Breitner wrote:

Hi,

Am Dienstag, den 24.01.2017, 10:37 +0000 schrieb Matthew Pickering:

...

If you have any example queries that you run often or queries which you have embedded into wikipages then it would be useful to share them so I can investigate.

the embedded query on https://ghc.haskell.org/trac/ghc/wiki/Newcomers is pretty useful. But as you point out, that is still possible (if we migrate the wiki as well…)

Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs