[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: will kahn-greene
Subject: Re: [GMG-Devel] redmine -> trac: status; please read
Date: Tue, 24 Jan 2012 09:31:28 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

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 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]