[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:22:30 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 |
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
- [GMG-Devel] redmine -> trac: status; please read, Will Kahn-Greene, 2012/01/23
- Re: [GMG-Devel] redmine -> trac: status; please read, Nathan Yergler, 2012/01/24
- Re: [GMG-Devel] redmine -> trac: status; please read,
will kahn-greene <=
- Re: [GMG-Devel] redmine -> trac: status; please read, Christopher Allan Webber, 2012/01/24
- Re: [GMG-Devel] redmine -> trac: status; please read, will kahn-greene, 2012/01/24
- Re: [GMG-Devel] redmine -> trac: status; please read, Valentin Villenave, 2012/01/24
- Re: [GMG-Devel] redmine -> trac: status; please read, will kahn-greene, 2012/01/24
- Re: [GMG-Devel] redmine -> trac: status; please read, Valentin Villenave, 2012/01/24
- Re: [GMG-Devel] redmine -> trac: status; please read, will kahn-greene, 2012/01/24
- Re: [GMG-Devel] redmine -> trac: status; please read, Valentin Villenave, 2012/01/24