[postgis-devel] GH Issues Migration Report Out

[Paul Ramsey]

As we all know, svn2git migration is pretty trivial. However, to achieve
the full power of being within the GH community, having our tickets also in
GH is important. It's also hard to do.

So, I've burned the better part of several days prototyping this, since
none of the "as built" scripts lying around the internets did everything we
wanted, and GH technology has improved since many of them were built. As I
saw it, the migration should

- convert r1234 references to hash references
- convert #1234 ticket references correctly (just ensuring 1:1 ticket #
equivalence achieves this)
- convert trac markup as much as possible into markdown
- retain as much metadata (milestones, priorities, components) as make sense

Some issues come up right away:

- GH issues just have labels, so a complete mapping of all trac attributes
can result in very noisy tickets. Some culling of "defaults" makes sense,
but that's easy enough.
  - Milestones are handled separately in GH, so that attribute moves across
cleanly.
  - Resolution types, components, priorities have to become labels. Color
can be used to inform "typology".
  - All this ends up being editorial choices, not impossible at all.
- GH API won't let you create new objects on behalf of someone else. Net
effect being, all migrated issues and comments end up owned by the creating
entity. Of course, once migration is done, ownership of new things is
correctly handled. You can see the effect of this in the mapserver
migration: https://github.com/mapserver/mapserver/issues/2154
- New beta GH Issue Import API does allow issues/comments to be
"back-dated", so a comment from 2012 will have a 2012 date. This is very
nice.
- Issue API in general won't allow tickets to be assigned to folks who
aren't in the organization of the repo being worked on. For my example
imports, this resulted in no ticket assignment. For a real migration, this
would limit our ability to assign to just folks in our postgis organization.
- The new beta GH Issue Import API didn't seem to like my milestones, for
reasons currently being looked into.

Long and short of it, since folks are basically saying "never never never",
I am demotivated to complete the investigation and get the "most perfect"
migration I can to show you all what it would look like. I have a migration
that is slightly better than the mapserver one (dates are correct on
tickets, and all the revision references are remapped to hash references)
but if there's no enthusiasm for getting into that larger pool, I'm going
to stop swimming and return to other, more useful work for my employer.

P.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171016/6b7e0f0e/attachment.html>