[postgis-devel] GH Issues Migration Report Out

[Regina Obe]

Never never never.  Why on earth would we want to move tickets to github.  What headache does that buy us aside form more people bitching about problems they are too lazy to pull up their sleeves to help fix.

 

Pull requests are already happening in github.  I don't see anyone that inconvenienced by that aside from some history being lost.  Which can be solved simply by moving to A git.

 

A git – YES

Github – NO

 

 

And do all users have github accounts.  Developers yes.  Users I would say not.  Hell 50% of my PostGIS client base does not have a github account and 30% don't even know what github is.

 

You've been hanging around way too many developers Paul.  Get your head out of the sand.

 

I hope that demotivates you enough.

 

Thanks,

Regina

 

 

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Monday, October 16, 2017 3:40 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: [postgis-devel] GH Issues Migration Report Out

 

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/8c86e4b6/attachment.html>