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

[Nathan Yergler]

I think http://trac.edgewall.org/wiki/WikiRestructuredText and
http://trac.edgewall.org/wiki/WikiHtml might be useful. The only
potentially annoying thing about the former is that it has a custom
role for intra-Trac links.

On Tue, Jan 24, 2012 at 6:31 AM, will kahn-greene <address@hidden> wrote:
> It just occurred to me that we could do a two-step conversion: Markdown
> --(pandoc)--> some-format --(some-other-tool)--> Trac markup.
>
> Also, the Trac documentation suggests we can use reST, HTML, and
> Textile:
>
> http://trac.edgewall.org/wiki/TracWiki
>
> So, if anyone was looking into that, hold off--I'll look into it more
> later with the hunch it's probably just a one-liner at the top of the
> comment stating what format the comment is in.
>
>
> On Tue 24 Jan 2012 09:22:30 AM EST, will kahn-greene wrote:
>> On Tue 24 Jan 2012 02:00:31 AM EST, Nathan Yergler wrote:
>>>
>>> On Mon, Jan 23, 2012 at 6:59 PM, Will Kahn-Greene <address@hidden> wrote:
>>>>
>>>> 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."
>>
>> I have the redmine relation data available and can totally add a
>> comment to the end of the trac ticket. I'm already adding one that has
>> a link to the original redmine issue in the Foocorp tracker. So this is
>> pretty easy to do and I can add the information to that comment.
>>
>> This is true of any other information we want to add, too.
>>
>>
>>>> 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.
>>
>> It's not automated, yet, but I plan to write a script to do it. If I
>> don't do this, then new accounts won't be associated with existing data
>> which I think is a big problem.
>>
>>
>>> 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.
>>
>> Aha! So the problem I have is that I'm getting the Redmine data with a
>> scraper. I don't have access to the usernames, passwords, or email
>> addresses. A while back when I was talking to Elrond about this, we
>> were thinking that I could solicit account information from people
>> before the migration, create the accounts as part of the migration, and
>> automatically map everything during the migration. I can do that, but I
>> suspect I won't be able to get accounts for everyone and will have to
>> write a script to map people post-migration anyhow.
>>
>>
>>>> 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.)
>>
>> I don't know for sure if supports HTML in comments, but I suspect not.
>>
>> I was looking at pandoc because it supports Markdown as an input
>> language. Pandoc supports the following output formats:
>>
>> native, json, html, html+lhs, s5, slidy, docbook, opendocument, latex,
>> latex+lhs, context, texinfo, man, markdown, markdown+lhs, plain, rst,
>> rst+lhs, mediawiki, textile, rtf, org, odt, epub
>>
>> I was tossing around converting it to plain text. It's possible the
>> Trac markup is really close to one of the above output formats and we
>> could use that instead. I could spend a bit of time looking into that,
>> but if anyone knew offhand, that'd be better. Here's a pared down list
>> of possible candidates and formats I know nothing about:
>>
>> slidy, context, rst, rst+lhs, mediawiki, textile
>>
>> The Trac formatting help page is here:
>> http://trac.edgewall.org/wiki/WikiFormatting
>>
>> Alternatively, if I'm wrong about what Trac supports, that'd be super,
>> too.
>>
>> Can someone volunteer to look at one of these two possibilities in the
>> next few days?
>>
>> /will
>>
>>
>> _______________________________________________
>> devel mailing list
>> address@hidden
>> http://lists.mediagoblin.org/listinfo/devel