Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

gt; | 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 speci

RE: Trac to Phabricator (Maniphest) migration prototype

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

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 -

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

> 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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

> 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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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.

Re: Trac to Phabricator (Maniphest) migration prototype

> 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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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

Re: Trac to Phabricator (Maniphest) migration prototype

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:

Re: Trac to Phabricator (Maniphest) migration prototype

> 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

Re: Trac to Phabricator (Maniphest) migration prototype

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?

Trac to Phabricator (Maniphest) migration prototype

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