Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Ben Gamari]

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


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

There is an equivalent, it is called Phriction -
https://phabricator.haskell.org/w/

I am not proposing at this stage that we migrate the wiki contents as
well. That would certainly be a logical next step but I think trac's
wiki is quite a bit better.

Matt

On Tue, Jan 10, 2017 at 12:00 PM, Simon Peyton Jones
<simo...@microsoft.com> wrote:
> 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-boun...@haskell.org] On Behalf Of Matthew
> |  Pickering
> |  Sent: 10 January 2017 11:59
> |  To: Richard Eisenberg <r...@cs.brynmawr.edu>
> |  Cc: GHC developers <ghc-devs@haskell.org>
> |  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=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb843
> |  
> 78ec2a08d439502937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840
> |  067524=7KEVArFhp3bIBclu2Drh8hSn8d47Q1aXrhGRQVKp%2BwM%3D=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=02%7C01%7Csimo
> |  
> npj%40microsoft.com%7Cfe21d0babfb84378ec2a08d439502937%7C72f988bf86f141af91a
> |  
> b2d7cd011db47%7C1%7C0%7C636196463840067524=MfqbX%2BCzMtqf4wIRhe0MUqSN4
> |  l8l7oRiDO3IUIqb8ag%3D=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 <r...@cs.brynmawr.edu>
> |  wrote:
> |  >
> |  >> On Jan 9, 2017, at 6:41 AM, Matthew Pickering
> |  <matthewtpicker...@gmail.com> 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=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb84378ec2a08d4395029
> |  
> 37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840067524=mRz
> |  Phhzd1Xjqfbwz%2BTtfESWg4gbdSWx5gC2HpDUtSuM%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Trac to Phabricator (Maniphest) migration prototype

[Simon Peyton Jones via ghc-devs]

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-boun...@haskell.org] On Behalf Of Matthew
|  Pickering
|  Sent: 10 January 2017 11:59
|  To: Richard Eisenberg <r...@cs.brynmawr.edu>
|  Cc: GHC developers <ghc-devs@haskell.org>
|  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=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb843
|  78ec2a08d439502937%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840
|  067524=7KEVArFhp3bIBclu2Drh8hSn8d47Q1aXrhGRQVKp%2BwM%3D=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=02%7C01%7Csimo
|  npj%40microsoft.com%7Cfe21d0babfb84378ec2a08d439502937%7C72f988bf86f141af91a
|  b2d7cd011db47%7C1%7C0%7C636196463840067524=MfqbX%2BCzMtqf4wIRhe0MUqSN4
|  l8l7oRiDO3IUIqb8ag%3D=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 <r...@cs.brynmawr.edu>
|  wrote:
|  >
|  >> On Jan 9, 2017, at 6:41 AM, Matthew Pickering
|  <matthewtpicker...@gmail.com> 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=02%7C01%7Csimonpj%40microsoft.com%7Cfe21d0babfb84378ec2a08d4395029
|  37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636196463840067524=mRz
|  Phhzd1Xjqfbwz%2BTtfESWg4gbdSWx5gC2HpDUtSuM%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

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://secure.phabricator.com/T10349

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://secure.phabricator.com/book/phabricator/article/projects/

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

To first reply to the one specific reoccurring point about custom fields.

The problem with 'os' and 'architecture' is a philosophical one, in
what way are they any different to any other metadata for a ticket? I
am of the opinion that we should only include information when it is
relevant, a lot of the time these two fields are not.
Including the fields as a special case is in fact worse as users feel
obliged to complete them even when they are irrelevant. Users who are
interested in these platforms are interested in problems which are
specific.

These fields have been structured for over 10 years now, some options
have been barely used but still clutter all interfaces. Nearly 2000
tickets are tagged as relevant to `x86` which massively dwarfs the
other fields -- there is an assumption that unless otherwise stated
the problem is manifested on x86 as that is the default use case.
What's more, just by browsing tickets categorised with this meta data,
it is often evident from the title that the problem is on a
non-default operating system. The assumption in this case is some
debian derivation, users reporting issues on other operating systems
include the operating system prominently as they know it is not
standard. (For example -
https://ghc.haskell.org/trac/ghc/query?os=MacOS+X=priority)

Stats for architecture - https://phabricator.haskell.org/P133

Stats for operating system - https://phabricator.haskell.org/P134

I modified my local install of phab to add custom fields,

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/M1/7/

The results were better than I remembered but I am unsatisfied that
they behave differently to projects and clutter up the description of
each ticket when they are "unset".


On the other hand, I think custom fields are suitable for things like
test case, wikipage etc. It is easy to add a field to carry over the
test case but I always found it a bit redundant as by looking at the
commit information you could work out which test is relevant to which
commit.

So to summarise I think..

Component -> Projects
OS -> (Sub)Projects
Arch -> (Sub)Projects
Keywords -> Projects
Version -> Remove (It is a proxy for date reported)
Milestone -> Project (Milestone)

Matt

On Sun, Jan 8, 2017 at 2:32 PM, Richard Eisenberg  wrote:
>
>> 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 

Re: Trac to Phabricator (Maniphest) migration prototype

[Richard Eisenberg]

> 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


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

Re: Trac to Phabricator (Maniphest) migration prototype

[Ben Gamari]

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 

Re: Trac to Phabricator (Maniphest) migration prototype

[Phyx]

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Richard Eisenberg]

> On Jan 4, 2017, at 5: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).

This seems sensible, yes.

> 
> 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 still strongly disagree with you here. You've described the first thing *you* 
do when working on a ticket, but that's not the first thing *I* do. My first 
step is to decide whether or not a care about a ticket, roughly like this:

- Read ticket title. If it's not about my area, stop.

- If the ticket is obviously a bug (panic, core lint error):
  * Check the version reported. If the version is old and I'm squeezed for time 
at the moment, stop.
  * Try to reproduce at the version reported. If I can't, report this on the 
ticket.
  * If HEAD is around on my machine and I'm sufficiently interested, try to 
repro on HEAD. Report my findings.

- If the ticket is not obviously a bug (complicated type-level shenanigans that 
is either accepted or rejected):
  * Think Hard about whether behavior is expected or not and report accordingly.
  * If behavior is indeed a bug, continue with the steps outlined above.

Note that version numbers play a key role in the triage process! If we had a 
bot that could try to repro every reported bug on HEAD and could report its 
findings, I would find the need for a version number less pressing. But until 
then, it's very very helpful.

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

Indeed. And I think using a tag list instead of the current keywords/component 
interface would be an improvement. At the same time, we need to identify 
workflows that go well with Trac but which might be disrupted in the 
changeover. I'm not arguing that any disrupted workflows are a deal-breaker, 
but we need to know what they are.

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

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/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 | 146445422344
>  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 | 122514038300
>  libraries/random| 4 | 1404824781090514
>  libraries/directory | 4 | 135592649600
>  External Core   | 4 | 136585569800
>  libraries/pretty| 4 | 132174375900
>  ghc-pkg | 4 | 1447954686599857
>  GHC API | 3 | 1463577929270933
>  libraries/HGL   | 3 | 121496144400
>  Prelude | 2 | 131361703700
>  libraries/haskell98 | 1 | 118669558100
>  libraries (old-time)| 1 | 121542625600
>  Visual Haskell  | 1 | 116643030700
>  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 +:
>>> 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.  

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

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 | 146445422344
 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 | 122514038300
 libraries/random| 4 | 1404824781090514
 libraries/directory | 4 | 135592649600
 External Core   | 4 | 136585569800
 libraries/pretty| 4 | 132174375900
 ghc-pkg | 4 | 1447954686599857
 GHC API | 3 | 1463577929270933
 libraries/HGL   | 3 | 121496144400
 Prelude | 2 | 131361703700
 libraries/haskell98 | 1 | 118669558100
 libraries (old-time)| 1 | 121542625600
 Visual Haskell  | 1 | 116643030700
 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 +:
>> 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 

Re: Trac to Phabricator (Maniphest) migration prototype

[Edward Z. Yang]

Excerpts from Matthew Pickering's message of 2017-01-03 23:32:42 +:
> 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?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Richard Eisenberg]

On 1/3/17 6:32 PM, Matthew Pickering wrote:

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.
I strongly disagree here. It is not uncommon to have a user report a bug 
against an old version of GHC. When the reporter sets a version of, say, 
7.6.3 these days, we know that the bug is quite clearly old and may 
already be fixed.

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 use the Template Haskell component field to quickly search for all TH 
tickets. That said, the line between Component and Keyword is very murky 
and ought to be straightened out. I'm thus not against scrapping 
Component, but I wouldn't want data loss during the conversion: an 
updated Component field should be retained as a tag.


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

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Edward Z. Yang]

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?

2. Following on to this, I am actually a fan of Trac having a
   separate field per logically distinct field, rather than GitHub
   style "EVERYTHING IS A TAG".  The primary reason for this
   is during bug submission: I find that if everything is a tag,
   they all show up in a giant list of ALL THE TAGS, and I never
   bother adding all the fields I should.  Whereas in Trac, every
   relevant field is in front of me, and I remember to toggle things
   as necessary.  Sometimes they don't matter, but sometimes
   they do (e.g., arch!) and I think *seeing* every field you might
   want to field in is helpful for remembering, at least for me
   as an expert user.

3. One thing that is bad about Trac is that its built-in search
   bar is useless.  So here, Phabricator is an improvement.  However,
   it seems like Phabricator search is less good than Trac's
   advanced ticket query.  Here's what I like about Trac's version:

- It sorts by priority, and then by ticket number. There is
  a long tail of bugs that I don't really care about, and
  this sorting helps me ignore the low priority ones which
  I don't care about.  I find sort-by-relevance *particularly
  frustrating* because I find that these search engines don't
  have particularly good relevance metrics, and the chronology
  hint of sorting by ticket number is much better.
  Phabricator doesn't offer any control over search.

- Trac search devotes only one row per ticket, so it is
  really easy to scan through and find the one I'm looking for.
  Both GH and Phabricator insist on putting a useless second
  row, fluffing up the results and making it difficult to
  scan.

- It searches tickets only. In Phabricator I always have to
  type in "Maniphest Task" into document types to get into the
  bug finding view. Maybe there's a way to setup default search
  for something like this?

Thanks,
Edward

Excerpts from Matthew Pickering's message of 2016-12-21 10:12:56 +:
> 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.
> 
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
> 
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
> 
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
> 
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
> 
> Further information below!
> 
> Matt
> 
> =
> 
> Reasons
> ==
> 
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
> 
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
> 
> 
> Why is Phabricator better?
> 
> 
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the 

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

Thanks everyone for the comments so far.

If you use Trac regularly then please comment. Thinking this is a bad
idea but not commenting is not particularly useful as it leaves
everyone
in a limbo.

I moved the site to a smaller instance so it would cost me less money to host.

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

Matt

On Wed, Dec 21, 2016 at 10:12 AM, Matthew Pickering
 wrote:
> 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.
>
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
>
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
>
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
>
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
>
> Further information below!
>
> Matt
>
> =
>
> Reasons
> ==
>
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
>
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
>
>
> Why is Phabricator better?
> 
>
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the usability of the
> issue tracker. I will list a few but I urge you to try it out.
>
> * Commits which mention ticket numbers are currently posted as trac
> comments. There is better integration in phabricator as linking to
> commits has first-class support.
> * Links with differentials are also more direct than the current
> custom field which means you must update two places when posting a
> differential.
> * Fields are verified so that mispelling user names is not possible
> (see #12623 where Ben mispelled his name for example)
> * This is also true for projects and other fields. Inspecting these
> fields on trac you will find that the formatting on each ticket is
> often quite different.
> * Keywords are much more useful as the set of used keywords is discoverable.
> * Related tickets are much more substantial as the status of related
> tickets is reflected to parent ticket.
> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
>
> Implementation
> 
>
> Keywords are implemented as projects. A project is a combination of a
> tag which can be used with any Phabricator object, a workboard to
> organise tasks and a group of people who care about the topic. Not all
> keywords are migrated. Only keywords with at least 5 tickets were
> added to avoid lots of useless projects. The state of keywords is
> still a bit unsatisfactory but I wanted to take this chance to clean
> them up.
>
> Custom fields such as architecture and OS are replaced by *projects*
> just like keywords. This has the same advantage as other projects.
> Users can be subscribed to projects and receive emails when new
> tickets are tagged with a project. The large majority of tickets have
> very little additional metadata set. I also implemented these as
> custom fields but found the the result to be less satisfactory.
>
> Some users who have trac accounts do not have phab accounts.
> Fortunately it is easy to create new user accounts for these users
> which have empty passwords which can be recovered by the appropriate
> email address. This means tickets can be properly attributed in the
> migration.
>
> The ticket numbers are maintained. I still advocate moving the
> infrastructure tickets in order to maintain this mapping. Especially
> as there has been little activity in thr the last year.
>
> Tickets are linked to the relevant 

Re: Trac to Phabricator (Maniphest) migration prototype

[Richard Eisenberg]

> On Dec 21, 2016, at 10:02 AM, Matthew Pickering  
> wrote:
> 
> Then looking at the culprits for some fun:
> 
> (simonpj,192)
> (goldfire,123)
> (bgamari,116)
> (thomie,102)
> (nomeata,30)
> (rwbarton,28)
> (RyanGlScott,19)
> (simonmar,18)

Ha. I also use the long form comment:XX:ticket:YY sometimes, for cross-ticket 
and from-wiki comment referencing. These are somewhat rare, but I doubt it 
would be hard to preserve this form, if you're aware of it.

Thanks for looking into it!

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

Re: Trac to Phabricator (Maniphest) migration prototype

[Manuel M T Chakravarty]

This looks good!

Manuel

> Am 21.12.2016 um 21:12 schrieb Matthew Pickering 
> :
> 
> 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.
> 
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
> 
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
> 
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
> 
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
> 
> Further information below!
> 
> Matt
> 
> =
> 
> Reasons
> ==
> 
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
> 
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
> 
> 
> Why is Phabricator better?
> 
> 
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the usability of the
> issue tracker. I will list a few but I urge you to try it out.
> 
> * Commits which mention ticket numbers are currently posted as trac
> comments. There is better integration in phabricator as linking to
> commits has first-class support.
> * Links with differentials are also more direct than the current
> custom field which means you must update two places when posting a
> differential.
> * Fields are verified so that mispelling user names is not possible
> (see #12623 where Ben mispelled his name for example)
> * This is also true for projects and other fields. Inspecting these
> fields on trac you will find that the formatting on each ticket is
> often quite different.
> * Keywords are much more useful as the set of used keywords is discoverable.
> * Related tickets are much more substantial as the status of related
> tickets is reflected to parent ticket.
> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
> 
> Implementation
> 
> 
> Keywords are implemented as projects. A project is a combination of a
> tag which can be used with any Phabricator object, a workboard to
> organise tasks and a group of people who care about the topic. Not all
> keywords are migrated. Only keywords with at least 5 tickets were
> added to avoid lots of useless projects. The state of keywords is
> still a bit unsatisfactory but I wanted to take this chance to clean
> them up.
> 
> Custom fields such as architecture and OS are replaced by *projects*
> just like keywords. This has the same advantage as other projects.
> Users can be subscribed to projects and receive emails when new
> tickets are tagged with a project. The large majority of tickets have
> very little additional metadata set. I also implemented these as
> custom fields but found the the result to be less satisfactory.
> 
> Some users who have trac accounts do not have phab accounts.
> Fortunately it is easy to create new user accounts for these users
> which have empty passwords which can be recovered by the appropriate
> email address. This means tickets can be properly attributed in the
> migration.
> 
> The ticket numbers are maintained. I still advocate moving the
> infrastructure tickets in order to maintain this mapping. Especially
> as there has been little activity in thr the last year.
> 
> Tickets are linked to the relevant commits, differentials and other
> tickets. There are 3000 dummy differentials which are used to test
> that the linking works correctly. Of course with real data, the proper
> differential would be
> linked.(http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T11044)
> 
> There are a couple of 

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

Ahh, nightmare. The address changed on the reboot -- here is the new address.

http://ec2-52-211-40-21.eu-west-1.compute.amazonaws.com\

Matt

On Wed, Dec 21, 2016 at 10:12 AM, Matthew Pickering
 wrote:
> 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.
>
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
>
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
>
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
>
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
>
> Further information below!
>
> Matt
>
> =
>
> Reasons
> ==
>
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
>
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
>
>
> Why is Phabricator better?
> 
>
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the usability of the
> issue tracker. I will list a few but I urge you to try it out.
>
> * Commits which mention ticket numbers are currently posted as trac
> comments. There is better integration in phabricator as linking to
> commits has first-class support.
> * Links with differentials are also more direct than the current
> custom field which means you must update two places when posting a
> differential.
> * Fields are verified so that mispelling user names is not possible
> (see #12623 where Ben mispelled his name for example)
> * This is also true for projects and other fields. Inspecting these
> fields on trac you will find that the formatting on each ticket is
> often quite different.
> * Keywords are much more useful as the set of used keywords is discoverable.
> * Related tickets are much more substantial as the status of related
> tickets is reflected to parent ticket.
> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
>
> Implementation
> 
>
> Keywords are implemented as projects. A project is a combination of a
> tag which can be used with any Phabricator object, a workboard to
> organise tasks and a group of people who care about the topic. Not all
> keywords are migrated. Only keywords with at least 5 tickets were
> added to avoid lots of useless projects. The state of keywords is
> still a bit unsatisfactory but I wanted to take this chance to clean
> them up.
>
> Custom fields such as architecture and OS are replaced by *projects*
> just like keywords. This has the same advantage as other projects.
> Users can be subscribed to projects and receive emails when new
> tickets are tagged with a project. The large majority of tickets have
> very little additional metadata set. I also implemented these as
> custom fields but found the the result to be less satisfactory.
>
> Some users who have trac accounts do not have phab accounts.
> Fortunately it is easy to create new user accounts for these users
> which have empty passwords which can be recovered by the appropriate
> email address. This means tickets can be properly attributed in the
> migration.
>
> The ticket numbers are maintained. I still advocate moving the
> infrastructure tickets in order to maintain this mapping. Especially
> as there has been little activity in thr the last year.
>
> Tickets are linked to the relevant commits, differentials and other
> tickets. There are 3000 dummy differentials which are used to test
> that the linking works correctly. Of course with real data, the proper
> differential would be
> 

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

I just noticed that the instance was down because the disk quota had
been reached. I expanded the size of storage and it should be working
again.

Matt

On Wed, Dec 21, 2016 at 10:12 AM, Matthew Pickering
 wrote:
> 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.
>
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
>
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
>
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
>
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
>
> Further information below!
>
> Matt
>
> =
>
> Reasons
> ==
>
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
>
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
>
>
> Why is Phabricator better?
> 
>
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the usability of the
> issue tracker. I will list a few but I urge you to try it out.
>
> * Commits which mention ticket numbers are currently posted as trac
> comments. There is better integration in phabricator as linking to
> commits has first-class support.
> * Links with differentials are also more direct than the current
> custom field which means you must update two places when posting a
> differential.
> * Fields are verified so that mispelling user names is not possible
> (see #12623 where Ben mispelled his name for example)
> * This is also true for projects and other fields. Inspecting these
> fields on trac you will find that the formatting on each ticket is
> often quite different.
> * Keywords are much more useful as the set of used keywords is discoverable.
> * Related tickets are much more substantial as the status of related
> tickets is reflected to parent ticket.
> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
>
> Implementation
> 
>
> Keywords are implemented as projects. A project is a combination of a
> tag which can be used with any Phabricator object, a workboard to
> organise tasks and a group of people who care about the topic. Not all
> keywords are migrated. Only keywords with at least 5 tickets were
> added to avoid lots of useless projects. The state of keywords is
> still a bit unsatisfactory but I wanted to take this chance to clean
> them up.
>
> Custom fields such as architecture and OS are replaced by *projects*
> just like keywords. This has the same advantage as other projects.
> Users can be subscribed to projects and receive emails when new
> tickets are tagged with a project. The large majority of tickets have
> very little additional metadata set. I also implemented these as
> custom fields but found the the result to be less satisfactory.
>
> Some users who have trac accounts do not have phab accounts.
> Fortunately it is easy to create new user accounts for these users
> which have empty passwords which can be recovered by the appropriate
> email address. This means tickets can be properly attributed in the
> migration.
>
> The ticket numbers are maintained. I still advocate moving the
> infrastructure tickets in order to maintain this mapping. Especially
> as there has been little activity in thr the last year.
>
> Tickets are linked to the relevant commits, differentials and other
> tickets. There are 3000 dummy differentials which are used to test
> that the linking works correctly. Of course with real data, the proper
> differential would 

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

I was interested to see how many times the raw comment syntax was used
as I don't use it myself.

Here are the three queries I ran.

-- Occurrences of the piece of syntax
SELECT COUNT(*) FROM ticket_change WHERE field='comment' AND newvalue
LIKE '%comment:%';
> 3783

-- Instances of the syntax from using the reply button
SELECT COUNT(*) FROM ticket_change WHERE field='comment' AND newvalue
LIKE '%[comment:%';
> 2957

-- Total comments
SELECT COUNT(*) FROM ticket_change WHERE field='comment';
> 75967

So the syntax is only used in about 1% of all comments.

Then looking at the culprits for some fun:

(simonpj,192)
(goldfire,123)
(bgamari,116)
(thomie,102)
(nomeata,30)
(rwbarton,28)
(RyanGlScott,19)
(simonmar,18)

were the most frequent comment referencers.

I don't think keeping these internal references would be too
difficult. I have now worked out where the number comes from and it is
easy to get.

Matt


On Wed, Dec 21, 2016 at 2:39 PM, Richard Eisenberg  wrote:
> I regularly use comment references on Trac, and I know others do, too. While 
> I'm not saying they need to be supported in a prototype before we elect to go 
> ahead with this route, I would say that preserving comment references is a 
> necessary part of this migration. Along similar lines, the comment numbers in 
> Trac are useful. Does Phab support human-readable comment numbers? Or only 
> those hashes? (I consider a 6-digit number too long to be human-readable.) 
> Having nice comment numbers isn't a necessary feature for me, but losing them 
> would be a small loss that might have to be balanced out by other gains.
>
> Thanks, Matthew, for doing this!
>
> For the record, this email does not express an opinion about the overall 
> merit of this move, just a few technical points. I do not have a considered 
> position on overall merit.
>
> Richard
>
>> On Dec 21, 2016, at 9:05 AM, Matthew Pickering  
>> wrote:
>>
>> I wondered if someone would ask me about this. In principle I don't
>> see why not but I don't immediately know how to get the correct label.
>>
>> In fact, this is an interesting example as "comment:21" refers to a
>> commit comment (https://ghc.haskell.org/trac/ghc/ticket/10547#comment:21)
>> which I have filtered out whilst doing the conversion and replaced by
>> actual links to the commits in a more idiomatic style. Thus
>> "comment:21" should actually point to #178376
>> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#178376).
>>
>>
>>
>> On Wed, Dec 21, 2016 at 1:54 PM, Sylvain Henry  wrote:
>>> Nice work!
>>>
>>> Would it be possible to convert comment references too? For instance in
>>> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#182793
>>> "comment:21" should be a link to the label #178747
>>>
>>> If we do the transfer, we should redirect:
>>>https://ghc.haskell.org/trac/ghc/ticket/{NN}#comment:{CC}
>>> to
>>>phabricator.haskell.org/T{NN}#{tracToPhabComment(NN,CC)}
>>> where "tracToPhabComment" function remains to be written ;-)
>>>
>>> Thanks,
>>> Sylvain
>>>
>>>
>>> On 21/12/2016 11:12, Matthew Pickering wrote:

 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.

 http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com

 All the user accounts are automatically generated. If you want to see
 the tracker from your perspective then send me an email or ping me on
 IRC and I can set the password of the relevant account.

 NOTE: This is not a decision, the existence of this prototype is to
 show that the migration is feasible in a satisfactory way and to
 remove hypothetical arguments from the discussion.

 I must also thank Dan Palmer and Herbert who helped me along the way.
 Dan was responsible for the first implementation and setting up much
 of the infrastructure at the Haskell Exchange hackathon in October. We
 extensively used the API bindings which Herbert had been working on.

 Further information below!

 Matt

 =

 Reasons
 ==

 Why this change? The main argument is consolidation. Having many
 different services is confusing for new and old contributors.
 Phabricator has proved effective as a code review tool. It is modern
 and actively developed with a powerful feature set which we currently
 only use a small fraction of.

 Trac is showing signs of its age. It is old and slow, users regularly
 lose comments through accidently 

Re: Trac to Phabricator (Maniphest) migration prototype

[Richard Eisenberg]

I regularly use comment references on Trac, and I know others do, too. While 
I'm not saying they need to be supported in a prototype before we elect to go 
ahead with this route, I would say that preserving comment references is a 
necessary part of this migration. Along similar lines, the comment numbers in 
Trac are useful. Does Phab support human-readable comment numbers? Or only 
those hashes? (I consider a 6-digit number too long to be human-readable.) 
Having nice comment numbers isn't a necessary feature for me, but losing them 
would be a small loss that might have to be balanced out by other gains.

Thanks, Matthew, for doing this!

For the record, this email does not express an opinion about the overall merit 
of this move, just a few technical points. I do not have a considered position 
on overall merit.

Richard

> On Dec 21, 2016, at 9:05 AM, Matthew Pickering  
> wrote:
> 
> I wondered if someone would ask me about this. In principle I don't
> see why not but I don't immediately know how to get the correct label.
> 
> In fact, this is an interesting example as "comment:21" refers to a
> commit comment (https://ghc.haskell.org/trac/ghc/ticket/10547#comment:21)
> which I have filtered out whilst doing the conversion and replaced by
> actual links to the commits in a more idiomatic style. Thus
> "comment:21" should actually point to #178376
> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#178376).
> 
> 
> 
> On Wed, Dec 21, 2016 at 1:54 PM, Sylvain Henry  wrote:
>> Nice work!
>> 
>> Would it be possible to convert comment references too? For instance in
>> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#182793
>> "comment:21" should be a link to the label #178747
>> 
>> If we do the transfer, we should redirect:
>>https://ghc.haskell.org/trac/ghc/ticket/{NN}#comment:{CC}
>> to
>>phabricator.haskell.org/T{NN}#{tracToPhabComment(NN,CC)}
>> where "tracToPhabComment" function remains to be written ;-)
>> 
>> Thanks,
>> Sylvain
>> 
>> 
>> On 21/12/2016 11:12, Matthew Pickering wrote:
>>> 
>>> 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.
>>> 
>>> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
>>> 
>>> All the user accounts are automatically generated. If you want to see
>>> the tracker from your perspective then send me an email or ping me on
>>> IRC and I can set the password of the relevant account.
>>> 
>>> NOTE: This is not a decision, the existence of this prototype is to
>>> show that the migration is feasible in a satisfactory way and to
>>> remove hypothetical arguments from the discussion.
>>> 
>>> I must also thank Dan Palmer and Herbert who helped me along the way.
>>> Dan was responsible for the first implementation and setting up much
>>> of the infrastructure at the Haskell Exchange hackathon in October. We
>>> extensively used the API bindings which Herbert had been working on.
>>> 
>>> Further information below!
>>> 
>>> Matt
>>> 
>>> =
>>> 
>>> Reasons
>>> ==
>>> 
>>> Why this change? The main argument is consolidation. Having many
>>> different services is confusing for new and old contributors.
>>> Phabricator has proved effective as a code review tool. It is modern
>>> and actively developed with a powerful feature set which we currently
>>> only use a small fraction of.
>>> 
>>> Trac is showing signs of its age. It is old and slow, users regularly
>>> lose comments through accidently refreshing their browser. Further to
>>> this, the integration with other services is quite poor. Commits do
>>> not close tickets which mention them and the only link to commits is a
>>> comment. Querying the tickets is also quite difficult, I usually
>>> resort to using google search or my emails to find the relevant
>>> ticket.
>>> 
>>> 
>>> Why is Phabricator better?
>>> 
>>> 
>>> Through learning more about Phabricator, there are many small things
>>> that I think it does better which will improve the usability of the
>>> issue tracker. I will list a few but I urge you to try it out.
>>> 
>>> * Commits which mention ticket numbers are currently posted as trac
>>> comments. There is better integration in phabricator as linking to
>>> commits has first-class support.
>>> * Links with differentials are also more direct than the current
>>> custom field which means you must update two places when posting a
>>> differential.
>>> * Fields are verified so that mispelling user names is not possible
>>> (see #12623 where Ben mispelled his name for example)

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

I wondered if someone would ask me about this. In principle I don't
see why not but I don't immediately know how to get the correct label.

In fact, this is an interesting example as "comment:21" refers to a
commit comment (https://ghc.haskell.org/trac/ghc/ticket/10547#comment:21)
which I have filtered out whilst doing the conversion and replaced by
actual links to the commits in a more idiomatic style. Thus
"comment:21" should actually point to #178376
(http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#178376).



On Wed, Dec 21, 2016 at 1:54 PM, Sylvain Henry  wrote:
> Nice work!
>
> Would it be possible to convert comment references too? For instance in
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#182793
> "comment:21" should be a link to the label #178747
>
> If we do the transfer, we should redirect:
> https://ghc.haskell.org/trac/ghc/ticket/{NN}#comment:{CC}
> to
> phabricator.haskell.org/T{NN}#{tracToPhabComment(NN,CC)}
> where "tracToPhabComment" function remains to be written ;-)
>
> Thanks,
> Sylvain
>
>
> On 21/12/2016 11:12, Matthew Pickering wrote:
>>
>> 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.
>>
>> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
>>
>> All the user accounts are automatically generated. If you want to see
>> the tracker from your perspective then send me an email or ping me on
>> IRC and I can set the password of the relevant account.
>>
>> NOTE: This is not a decision, the existence of this prototype is to
>> show that the migration is feasible in a satisfactory way and to
>> remove hypothetical arguments from the discussion.
>>
>> I must also thank Dan Palmer and Herbert who helped me along the way.
>> Dan was responsible for the first implementation and setting up much
>> of the infrastructure at the Haskell Exchange hackathon in October. We
>> extensively used the API bindings which Herbert had been working on.
>>
>> Further information below!
>>
>> Matt
>>
>> =
>>
>> Reasons
>> ==
>>
>> Why this change? The main argument is consolidation. Having many
>> different services is confusing for new and old contributors.
>> Phabricator has proved effective as a code review tool. It is modern
>> and actively developed with a powerful feature set which we currently
>> only use a small fraction of.
>>
>> Trac is showing signs of its age. It is old and slow, users regularly
>> lose comments through accidently refreshing their browser. Further to
>> this, the integration with other services is quite poor. Commits do
>> not close tickets which mention them and the only link to commits is a
>> comment. Querying the tickets is also quite difficult, I usually
>> resort to using google search or my emails to find the relevant
>> ticket.
>>
>>
>> Why is Phabricator better?
>> 
>>
>> Through learning more about Phabricator, there are many small things
>> that I think it does better which will improve the usability of the
>> issue tracker. I will list a few but I urge you to try it out.
>>
>> * Commits which mention ticket numbers are currently posted as trac
>> comments. There is better integration in phabricator as linking to
>> commits has first-class support.
>> * Links with differentials are also more direct than the current
>> custom field which means you must update two places when posting a
>> differential.
>> * Fields are verified so that mispelling user names is not possible
>> (see #12623 where Ben mispelled his name for example)
>> * This is also true for projects and other fields. Inspecting these
>> fields on trac you will find that the formatting on each ticket is
>> often quite different.
>> * Keywords are much more useful as the set of used keywords is
>> discoverable.
>> * Related tickets are much more substantial as the status of related
>> tickets is reflected to parent ticket.
>> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
>>
>> Implementation
>> 
>>
>> Keywords are implemented as projects. A project is a combination of a
>> tag which can be used with any Phabricator object, a workboard to
>> organise tasks and a group of people who care about the topic. Not all
>> keywords are migrated. Only keywords with at least 5 tickets were
>> added to avoid lots of useless projects. The state of keywords is
>> still a bit unsatisfactory but I wanted to take this chance to clean
>> them up.
>>
>> Custom fields such as architecture and OS are replaced by *projects*
>> just like keywords. This has the same advantage as other projects.

Re: Trac to Phabricator (Maniphest) migration prototype

[Sylvain Henry]

Nice work!

Would it be possible to convert comment references too? For instance in 
http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T10547#182793 
"comment:21" should be a link to the label #178747


If we do the transfer, we should redirect:
https://ghc.haskell.org/trac/ghc/ticket/{NN}#comment:{CC}
to
phabricator.haskell.org/T{NN}#{tracToPhabComment(NN,CC)}

where "tracToPhabComment" function remains to be written ;-)

Thanks,
Sylvain

On 21/12/2016 11:12, Matthew Pickering wrote:

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.

http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com

All the user accounts are automatically generated. If you want to see
the tracker from your perspective then send me an email or ping me on
IRC and I can set the password of the relevant account.

NOTE: This is not a decision, the existence of this prototype is to
show that the migration is feasible in a satisfactory way and to
remove hypothetical arguments from the discussion.

I must also thank Dan Palmer and Herbert who helped me along the way.
Dan was responsible for the first implementation and setting up much
of the infrastructure at the Haskell Exchange hackathon in October. We
extensively used the API bindings which Herbert had been working on.

Further information below!

Matt

=

Reasons
==

Why this change? The main argument is consolidation. Having many
different services is confusing for new and old contributors.
Phabricator has proved effective as a code review tool. It is modern
and actively developed with a powerful feature set which we currently
only use a small fraction of.

Trac is showing signs of its age. It is old and slow, users regularly
lose comments through accidently refreshing their browser. Further to
this, the integration with other services is quite poor. Commits do
not close tickets which mention them and the only link to commits is a
comment. Querying the tickets is also quite difficult, I usually
resort to using google search or my emails to find the relevant
ticket.


Why is Phabricator better?


Through learning more about Phabricator, there are many small things
that I think it does better which will improve the usability of the
issue tracker. I will list a few but I urge you to try it out.

* Commits which mention ticket numbers are currently posted as trac
comments. There is better integration in phabricator as linking to
commits has first-class support.
* Links with differentials are also more direct than the current
custom field which means you must update two places when posting a
differential.
* Fields are verified so that mispelling user names is not possible
(see #12623 where Ben mispelled his name for example)
* This is also true for projects and other fields. Inspecting these
fields on trac you will find that the formatting on each ticket is
often quite different.
* Keywords are much more useful as the set of used keywords is discoverable.
* Related tickets are much more substantial as the status of related
tickets is reflected to parent ticket.
(http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)

Implementation


Keywords are implemented as projects. A project is a combination of a
tag which can be used with any Phabricator object, a workboard to
organise tasks and a group of people who care about the topic. Not all
keywords are migrated. Only keywords with at least 5 tickets were
added to avoid lots of useless projects. The state of keywords is
still a bit unsatisfactory but I wanted to take this chance to clean
them up.

Custom fields such as architecture and OS are replaced by *projects*
just like keywords. This has the same advantage as other projects.
Users can be subscribed to projects and receive emails when new
tickets are tagged with a project. The large majority of tickets have
very little additional metadata set. I also implemented these as
custom fields but found the the result to be less satisfactory.

Some users who have trac accounts do not have phab accounts.
Fortunately it is easy to create new user accounts for these users
which have empty passwords which can be recovered by the appropriate
email address. This means tickets can be properly attributed in the
migration.

The ticket numbers are maintained. I still advocate moving the
infrastructure tickets in order to maintain this mapping. Especially
as there has been little activity in thr the last year.

Tickets are linked to the relevant commits, differentials and other
tickets. There are 3000 dummy differentials which are used to test
that the 

Re: Trac to Phabricator (Maniphest) migration prototype

[Matthew Pickering]

> Is it possible for those like me who have a different username on trac and
> phabricator to get mapped correctly?

Yes, definitely. I would need to work out exactly what to do about
user accounts, for this I just created accounts with the same names.
There are two things to consider about a more intelligent mapping.

1. People who have different names on each site.
2. People who don't have phab accounts but do have trac accounts.

>
> And how does the ticket creation process look? I tried it but needed to
> login. Do you get a set of projects you have to pick? Like the custom fields
> we have now or is it just one box where you have to add stuff to all in one
> line?
>

I sent you some login details so you can try it out.

> Kind regards,
> Tamar

Matt

>
> On Wed, 21 Dec 2016, 10:13 Matthew Pickering, 
> wrote:
>>
>> 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.
>>
>> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
>>
>> All the user accounts are automatically generated. If you want to see
>> the tracker from your perspective then send me an email or ping me on
>> IRC and I can set the password of the relevant account.
>>
>> NOTE: This is not a decision, the existence of this prototype is to
>> show that the migration is feasible in a satisfactory way and to
>> remove hypothetical arguments from the discussion.
>>
>> I must also thank Dan Palmer and Herbert who helped me along the way.
>> Dan was responsible for the first implementation and setting up much
>> of the infrastructure at the Haskell Exchange hackathon in October. We
>> extensively used the API bindings which Herbert had been working on.
>>
>> Further information below!
>>
>> Matt
>>
>> =
>>
>> Reasons
>> ==
>>
>> Why this change? The main argument is consolidation. Having many
>> different services is confusing for new and old contributors.
>> Phabricator has proved effective as a code review tool. It is modern
>> and actively developed with a powerful feature set which we currently
>> only use a small fraction of.
>>
>> Trac is showing signs of its age. It is old and slow, users regularly
>> lose comments through accidently refreshing their browser. Further to
>> this, the integration with other services is quite poor. Commits do
>> not close tickets which mention them and the only link to commits is a
>> comment. Querying the tickets is also quite difficult, I usually
>> resort to using google search or my emails to find the relevant
>> ticket.
>>
>>
>> Why is Phabricator better?
>> 
>>
>> Through learning more about Phabricator, there are many small things
>> that I think it does better which will improve the usability of the
>> issue tracker. I will list a few but I urge you to try it out.
>>
>> * Commits which mention ticket numbers are currently posted as trac
>> comments. There is better integration in phabricator as linking to
>> commits has first-class support.
>> * Links with differentials are also more direct than the current
>> custom field which means you must update two places when posting a
>> differential.
>> * Fields are verified so that mispelling user names is not possible
>> (see #12623 where Ben mispelled his name for example)
>> * This is also true for projects and other fields. Inspecting these
>> fields on trac you will find that the formatting on each ticket is
>> often quite different.
>> * Keywords are much more useful as the set of used keywords is
>> discoverable.
>> * Related tickets are much more substantial as the status of related
>> tickets is reflected to parent ticket.
>> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
>>
>> Implementation
>> 
>>
>> Keywords are implemented as projects. A project is a combination of a
>> tag which can be used with any Phabricator object, a workboard to
>> organise tasks and a group of people who care about the topic. Not all
>> keywords are migrated. Only keywords with at least 5 tickets were
>> added to avoid lots of useless projects. The state of keywords is
>> still a bit unsatisfactory but I wanted to take this chance to clean
>> them up.
>>
>> Custom fields such as architecture and OS are replaced by *projects*
>> just like keywords. This has the same advantage as other projects.
>> Users can be subscribed to projects and receive emails when new
>> tickets are tagged with a project. The large majority of tickets have
>> very little additional metadata set. I also implemented these as
>> custom fields but found the the result to be less satisfactory.
>>
>> Some 

Re: Trac to Phabricator (Maniphest) migration prototype

[Phyx]

Hi Matthew,

Great work! I must admit I'm one of the few that generally likes Trac but
I'm liking this quite a lot.

Just two questions,

Is it possible for those like me who have a different username on trac and
phabricator to get mapped correctly?

And how does the ticket creation process look? I tried it but needed to
login. Do you get a set of projects you have to pick? Like the custom
fields we have now or is it just one box where you have to add stuff to all
in one line?

Kind regards,
Tamar

On Wed, 21 Dec 2016, 10:13 Matthew Pickering, 
wrote:

> 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.
>
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
>
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
>
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
>
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
>
> Further information below!
>
> Matt
>
> =
>
> Reasons
> ==
>
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
>
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
>
>
> Why is Phabricator better?
> 
>
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the usability of the
> issue tracker. I will list a few but I urge you to try it out.
>
> * Commits which mention ticket numbers are currently posted as trac
> comments. There is better integration in phabricator as linking to
> commits has first-class support.
> * Links with differentials are also more direct than the current
> custom field which means you must update two places when posting a
> differential.
> * Fields are verified so that mispelling user names is not possible
> (see #12623 where Ben mispelled his name for example)
> * This is also true for projects and other fields. Inspecting these
> fields on trac you will find that the formatting on each ticket is
> often quite different.
> * Keywords are much more useful as the set of used keywords is
> discoverable.
> * Related tickets are much more substantial as the status of related
> tickets is reflected to parent ticket.
> (http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com/T7724)
>
> Implementation
> 
>
> Keywords are implemented as projects. A project is a combination of a
> tag which can be used with any Phabricator object, a workboard to
> organise tasks and a group of people who care about the topic. Not all
> keywords are migrated. Only keywords with at least 5 tickets were
> added to avoid lots of useless projects. The state of keywords is
> still a bit unsatisfactory but I wanted to take this chance to clean
> them up.
>
> Custom fields such as architecture and OS are replaced by *projects*
> just like keywords. This has the same advantage as other projects.
> Users can be subscribed to projects and receive emails when new
> tickets are tagged with a project. The large majority of tickets have
> very little additional metadata set. I also implemented these as
> custom fields but found the the result to be less satisfactory.
>
> Some users who have trac accounts do not have phab accounts.
> Fortunately it is easy to create new user accounts for these users
> which have empty passwords which can be recovered by the appropriate
> email address. This means tickets can be properly attributed in the
> migration.
>
> The ticket numbers are maintained. I still advocate moving the
>