[TIP] [unittest2] Issues DB migrated off of google code.

Donald Stufft donald at stufft.io
Wed Mar 18 21:56:58 PDT 2015


> On Mar 19, 2015, at 12:52 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> 
> Robert Collins <robertc at robertcollins.net> writes:
> 
>> GitLab's issue tracker isn't federated. (Few are).
> 
> According to <URL:https://about.gitlab.com/features/>, the issue tracker
> is part of the free-software GitLab. Do you have information otherwise?
> 
>> Thirdly, GitLab is no more or less federated than Github AFAICT
> 
> My point isn't about what features are there. My point is about what
> features are locked in to the provider — whether the (for example) issue
> tracker can be migrated, with the rest of the project, to a different
> provider retaining continuity.
> 
> GitHub fails on that.
> 
>> certainly googling found
>> http://feedback.gitlab.com/forums/176466-general/suggestions/5097708-implement-cross-server-federated-merge-requests
>> which shows its not federated today.
> 
> I see. Thanks for correcting my incorrect use of “federated”.
> 
> So I re-phrase the question: Can we move the issue tracker to a provider
> where it's not locked in?
> 
>> Fourthly, there's absolutely nothing morally wrong
> 
> Not the argument I was making. I am arguing from practical concerns:
> there are issue trackers which don't lock the project in, and those are
> a lower risk than a locked-in service.
> 
>> Fourthly GitLab *service* is absolutely proprietary.
> 
> My understanding is that a project hosting its issue tracker on
> GitLab.com can migrate to a free-software instance of GitLab, and keep
> moving forward with the same data from that point. Where is that
> incorrect?
> 
> --
> \     “Pinky, are you pondering what I'm pondering?” “Uh, I think so, |
>  `\         Brain, but we'll never get a monkey to use dental floss.” |
> _o__)                                           —_Pinky and The Brain_ |
> Ben Finney
> 
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python

Ironically, moving away from Github Issues is easier than moving *into* Github
issues. Github has a decent API that lets you access all your data that you can
use to move it out. The Github API does not let you import issues as someone
other than whatever account is doing the import, so it’s a lossy import.

Even if Github in some hypothetical future shuts down their API, it would be
pretty dificult for them to prevent people from just simply scraping the data
off of the HTML pages.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20150319/35f41439/attachment.pgp>


More information about the testing-in-python mailing list