Re: [GMG-Devel] redmine -> trac: status; please read

[will kahn-greene]

The reports should be easy to edit--they're in the conf file. I think
after we do the initial migration, we'll spend some time adapting Trac
to fit our needs. This work would include:

1. tweaking navigation links
2. changing the front page
3. changing the reports to ones we use--e.g. we'll want a report for
tickets that would be good for new contributors
4. style?
5. ...


On 01/24/2012 11:40 AM, Christopher Allan Webber wrote:
> Echoing Nathan, this is a huge pain of an infrastructure task, and thank
> you for taking it on!
> 
> My main comment would be that at the moment that when I look at the
> "active tickets" query, I'm surprised by how few show up.
> http://issues.mediagoblin.org/report/1 
> 
> But I guess this is actually because there's an "accepted" field in
> Trac, rather than readmine.  Looks like the issues are there:
> http://issues.mediagoblin.org/query
> 
> ... just not marked as "accepted".  I guess we'll need a new workflow to
> mark tasks as accepted?
> 
> Overall looks great to me, and fantastic work, Will!
> 
> Nathan Yergler <address@hidden> writes:
> 
>> Thanks for taking this on, Will; I'm sure it's not a minor task. A few
>> comments inline...
>>
>> On Mon, Jan 23, 2012 at 6:59 PM, Will Kahn-Greene <address@hidden> wrote:
>>>
>>> Please read this email. It's about the impending migration of MediaGoblin's
>>> bug data from the Redmine issue tracker we're using now to the Trac ticket
>>> tracker we'll be using in the very near future.
>>>
>>>
>>> I've got Trac 0.12 with the TracAccountManager plugin installed on
>>> http://issues.mediagoblin.org/ now. Additionally, I did a data migration
>>> from Redmine to Trac.
>>>
>>> There are a few things to know:
>>>
>>> 1. Redmine issues don't start with 1, so there's a mismatch between Redmine
>>> issues and Trac tickets.
>>>
>>> 2. All Trac tickets have an additional comment at the bottom that links back
>>> to the original Redmine issue.
>>>
>>> 3. Trac doesn't manage relationships between tickets: relates to, blocks,
>>> depends, duplicates, ... Trac allows you to resolve a ticket as a duplicate,
>>> but doesn't let you specify the ticket that it duplicates. In Trac you do
>>> that in the comments when you mark the ticket as a duplicate. My migration
>>> script doesn't do anything with the relations information at the moment. I'm
>>> open to ideas on what to do here.
>>
>> Is it possible to read the relationships out of the Redmine data? If
>> so maybe the migration script could do a second pass and add the
>> appropriate comments -- after it's imported the issues into Trac and
>> can map issue numbers from Redmine to Trac, the script could add a
>> comment "This ticket is a ${relationship}s of ${ticket_num}s."
>>
>>>
>>> 4. I haven't migrated any accounts over. So when we make this live:
>>>
>>>   1. people will create new accounts in Trac
>>>   2. let me know and I'll connect your account to tickets, attachments,
>>>      and changes
>>>
>>> If anyone has better ideas on what to do here, I'm all ears.
>>
>> Is step 2 above automated-ish for you? I'd hate to make a bunch of
>> manual work for you post-migration. Any reason not to make accounts
>> for the email addresses/usernames in Redmine and make people do
>> "forgot my password"? This sort of relates to #5 below.
>>
>>>
>>> 5. Trac has cc section in tickets, but it takes email addresses. Redmine
>>> issues have user accounts. Thus in order to connect the two, I need people
>>> to create accounts and such.
>>>
>>> However, this is a huge pain in the ass to populate after the fact. Is it ok
>>> if people re-cc: themselves to bugs they're interested in? If not, I'll
>>> spend the time to back-populate the data after the fact, but it'll probably
>>> take me a couple of weeks to get to.
>>>
>>> 6. I haven't closed any of the milestones. In Trac when a milestone is done,
>>> you close it out and then it doesn't show up in the active milestone list.
>>> I'll do that when we do a final migration, but I need to get the dates
>>> before I do.
>>>
>>> 7. Redmine issues text data is formatted in Markdown. Trac uses its own
>>> formatting markup. I just left the Redmine stuff as is, but it's ugly.
>>> Anyone have ideas on what to do here?
>>
>> Does Trac allow HTML in ticket text? (I couldn't find a clear answer
>> from briefly browsing the docs.) If so maybe something like pandoc
>> (http://johnmacfarlane.net/pandoc/) could help? (I don't know how
>> feasible that is, I just always think about it for formatting
>> conversion.)
>>
>>
>> Thanks again for taking this on, it's a huge job!
>>
>> NRY
>>
>>>
>>>
>>> I think that about covers it.
>>>
>>> Things I need help with:
>>>
>>> 1. I need people go to through the Trac tickets and see if there are issues
>>> I've missed.
>>>
>>> 2. If anyone has ideas on issues 3, 4, and 7 above, I'm interested.
>>>
>>>
>>> Going forward:
>>>
>>> I have a few minor things to tweak in my migration script.
>>>
>>> Additionally, I'd like to figure out what to do about issues 3, 4, and 7
>>> above.
>>>
>>> I'm planning to do a final migration in February. I'll probably disable
>>> everyone's Redmine access, do the final migration, then send an email to
>>> this list about what to do.
>>>
>>> Note that all the data currently at http://issues.mediagoblin.org/ will be
>>> dumped when I do the final migration!
>>>
>>>
>>> That's all I can think of. Sorry it's taken so long to do this, but it
>>> turned into a much larger undertaking than I wanted it to be.
>>>
>>> /will
>>> _______________________________________________
>>> devel mailing list
>>> address@hidden
>>> http://lists.mediagoblin.org/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> address@hidden
>> http://lists.mediagoblin.org/listinfo/devel