mediagoblin-devel
[Top][All Lists]
Advanced

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


reply via email to

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