[postgis-devel] GH Issues Migration Report Out

[Regina Obe]

1) It doesn't restrict the users I don't care about enough (e.g. stupid spambots and people too lazy to read the docs)
2) It restricts the users I do care about.   People who don't care to create a github account.  There are lot of those folks and many of them are what makes FOSS great.

How's that for more BS arguments.

The only benefit of github is it makes it easy for casual developers to give us pull requests.

It's much harder to create spammy pull requests than it is to create spammy or lazy tickets, so I'm okay with pull requests.

Strk was the first to think of that need by the way when he setup the mirroring on github.  I didn't see you all excited about it then.

Anyway people had some complaints about the mirror breaking.  That issue has since been resolved and it's pretty instantaneous at this point.

So what else can I possibly gain from having tickets on github or even having github as official repo.  So it's easier for you to click the Merge button?


Thanks,
Regina







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

You�re simultaneously arguing that GitHub doesn�t restrict folks enough (�what headache does that buy us aside form more people bitching�) and that it�s way too restrictive ("Hell 50% of my PostGIS client base does not have a github account�). 

Please choose just one BS argument and stick with it.

P.


> On Oct 16, 2017, at 12:49 PM, Regina Obe <lr at pcorp.us> wrote:
> 
> 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.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-devel