[Numpy-discussion] Migrating numpy Trac to github issues

[Ralf Gommers]

On Mon, Jun 11, 2012 at 4:11 PM, Thouis (Ray) Jones <thouis at gmail.com>wrote:

> I've volunteered to help manage the migration of numpy tickets from
> Trac to github issues.


Awesome, thanks!


> The first part of this process is to decide
> which tickets to migrate, and how to map Trac ticket data to github
> issue data.
>
> Question 1: Which tickets should be migrated?  Open?  Open and
> recently closed?  All tickets?
>
> If Trac is going to disappear eventually and it's not too much trouble,
all would be good.


> Question 2: Which parts of the tickets should be included, and in what way?
>
> For reference, these are the parts of a ticket (from
> http://trac.edgewall.org/wiki/TracTickets)
>
> Reporter
> Type (e.g., defect, enhancementt).
> Component
> Version
> Keywords
> Priority
> Milestone
> Assigned to/Owner
> Cc
> Resolution (fixed, invalid, wontfix, duplicate, worksforme, others?)
> Status (e.g., new, needs_review, etc.)
> Summary (brief description)
> Description (full description)
> Comments
> Attachments (not listed on the link above, but enabled for numpy Trac)
> ??? (Other) — I don't have access to the Trac configuration, so it's
> not clear if there are other fields I may be missing.
>
> As an initial suggestion, I propose:
>
> Reporter - yes, mapping Trac users to github users where possible.
>

And if not possible, include username in comment on Github? Also, consider
sending Trac users an email directly about the moved ticket?


> Type - yes, using github issues labels
> Component - yes, using labels
> Version - probably yes, using labels
>

I don't find version useful at all, so I'd prefer to leave it out.
Alternatively, keep as a comment on the issue. It's not important enough
for a label. Also, because users can't assign labels, it will be extra work
(which lands in comments) to attach this label to new issues after they're
reported.

Keywords - Yes, as a line in the github issue comments
> Priority - yes, using labels
> Milestone - yes, using github milestones
> Assigned to/Owner - yes, mapping to github users
> Cc - Yes, for github users we can map to, using @username
> Resolution - Only if tickets other than "open" are migrated, and as
> part of the issue comments
> Status - Yes, using labels
> Summary - Yes, as the github issue title
> Description - Yes, as the github issue body
> Comments - Yes, as github issue comments
> Attachments - Yes, linked in an issue comment
>

All agreed.


> Note that the Trac database will be available for some time, and every
> migrated ticket will include a link to the original.  If the Trac
> database is ever disabled, these links could be migrated to a static
> copy of the site.
>
> At some point, there may be a new location for ticket attachments,
> requiring changing links in some github issues.  That's a separate
> issue from this discussion.
>
> Trac allows WikiFormatting, while github has a more limited markup
> language.  As much translation as is possible will be performed within
> comments (code blocks, at an absolute minimum).
>

In practice, code blocks are probably enough.

>
> Tickets will be migrated to a test repository before being moved to
> the numpy github repo, and there will be ample time to review the
> result before proceeding beyond that step.
>

Sounds good.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120612/dfaad187/attachment.html>