This repository has been archived by the owner. It is now read-only.

Moving away from GitHub? #37

Closed
ollieparanoid opened this Issue Oct 9, 2017 · 57 comments

Comments

Projects
None yet
@ollieparanoid
Member

ollieparanoid commented Oct 9, 2017

It has been asked a few times, whether postmarketOS could be hosted on an open source platform (GitHub is not open source), such as gitlab - or maybe even go entirely self-hosted.

Personally I am happy with GitHub so far, because it's the lowest entry barrier for contributions to the project. Travis CI also works well for us (Travis is open source), so we would need something similar when moving.

Opinions?

@PabloCastellano

This comment has been minimized.

Member

PabloCastellano commented Oct 9, 2017

In my opinion, hosting our own Git infrastructure doesn't pay off.

GitHub is just the place where the development meets at the moment. It may change in the future and thanks to Git being distributed by design, you can easily mirror it in other platforms if you want to.

Maintenance is invisible work that needs to be done by someone and the trade-off for freedom in this case is good for me. GitHub offers very good tools and they support open source in many ways. The only controversial topic about GitHub that comes to my mind are DMCA requests which seem unlikely to affect to this project so far.

@kskarthik

This comment has been minimized.

Contributor

kskarthik commented Oct 10, 2017

My opinion

  • Registering an account Mirroring to gitlab temporarily will be nice.

  • I don't think there will be any entry barrier for gitlab, as it looks & functions like github in the same way. Also, gitlab facilitates logging in with github account.

@craftyguy

This comment has been minimized.

Member

craftyguy commented Oct 10, 2017

I've never really used gitlab, so there will be a slight modification to my workflow with the move. Having a CI (e.g. Travis) is also a big benefit to not only maintaining stability but also lowering barrier to entry by providing very quick feedback to new developers who make PRs.

Other than that, I would much rather prefer hosting on gitlab.com or github to hosting it ourselves due to the maintenance/backups/etc that @PabloCastellano mentioned.. that (hosting it ourselves) would, IMHO, add unnecessary overhead to the project.

@MartijnBraam

This comment has been minimized.

Member

MartijnBraam commented Oct 10, 2017

I have a self-hosted gitlab and it works very nice but we'd better host it on either gitlab.com or github to keep the barrier to entry low because gitlab is quite a big load on infra and the alternatives aren't as complete. (I do like the gitlab-ci very much though)

@z3ntu

This comment has been minimized.

Member

z3ntu commented Oct 13, 2017

I also agree that having the project on GitHub lowers the entry barrier quite a bit as many people are already familiar with the user interface and most likely have an account here.
Self-hosting isn't a good option right now as 1. the project is still quite small and 2. maintaining our own infrastructure is expensive and difficult to maintain.

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Nov 11, 2017

To sum up the opinions presented in this thread, as I read them:

  • No one is in favor of moving to our own infrastructure, because we don't have the resources to maintain it
  • There's no majority for moving to GitLab

There hasn't been any new input for about a month, so I'm closing this.

@kskarthik

This comment has been minimized.

Contributor

kskarthik commented Nov 12, 2017

But, I suggest to block the project names on gitlab if we change opinion in future.

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Nov 12, 2017

@kskarthik

This comment has been minimized.

Contributor

kskarthik commented Nov 13, 2017

Great!

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 3, 2018

Is anyone in favour of this being reopened. With the news of the acquisition I think some people maybe have changed thoughts on this.

Personally I think i would prefer the project to start moving away from GitHub as I don't really like the thought of Microsoft having a monopoly, this https://www.reddit.com/r/programming/comments/8ob3cl/microsoft_is_said_to_have_agreed_to_acquire/e024gva/ comment pretty much describes my view.

@craftyguy

This comment has been minimized.

Member

craftyguy commented Jun 3, 2018

I think that's still a rumor, but it'll happen sooner or later.. if not microsoft then someone else.

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 3, 2018

@craftyguy nope, see Bloomberg article, I doubt they would report something like that without a good source

@craftyguy

This comment has been minimized.

Member

craftyguy commented Jun 3, 2018

@kskarthik

This comment has been minimized.

Contributor

kskarthik commented Jun 4, 2018

Gitlab Importer is cool !

@PureTryOut

This comment has been minimized.

Contributor

PureTryOut commented Jun 4, 2018

If we actually start thinking about this, please don't dismiss alternatives to Gitlab. Gitea is also cool, and is interface-wise basically a copy of Github (which I like very much). Besides self-hosting it, you can also use a host like notabug.org for it.

@MayeulC

This comment has been minimized.

MayeulC commented Jun 4, 2018

I agree that's a bit concerning, but not too much; we should probably take a "wait-and-see" approach, while being careful not to lock ourselves in a vendor-specific solution that would make migrating too painful.

With that in mind, we could think about getting closer to freedesktop.org, maybe they could make some room for us on https://gitlab.freedesktop.org/ ?

All the while, other solutions such as Gitea are extremely lightweight to host, and provide a good UI (I think it is possible to integrate it with Travis, though I am not sure).

@MartijnBraam

This comment has been minimized.

Member

MartijnBraam commented Jun 4, 2018

I like gitlab a lot as alternative to github, mainly because the issue tracker is very decent and they have great CI integration (I also run gitlab on my homeserver for my internal projects)

@z3ntu

This comment has been minimized.

Member

z3ntu commented Jun 4, 2018

Travis only supports GitHub currently so with our current infrastructure it's not possible to just migrate.

(and I honestly don't want to. Also Microsoft is not acquiring GitHub to destroy it...)

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 4, 2018

Yeah, though I don't think anyone here is thinking they'll destroy it, just that Microsoft basically having a monopoly on code hosting is a bad idea.

Also, gitlab ci is pretty easy to migrate to and iirc their builders are a little faster.

@kskarthik

This comment has been minimized.

Contributor

kskarthik commented Jun 4, 2018

Its official now. Ms acquired github.

@craftyguy

This comment has been minimized.

Member

craftyguy commented Jun 4, 2018

Also Microsoft is not acquiring GitHub to destroy it...

Skype would like to talk to you.. but they can't because they were effectively destroyed

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Jun 4, 2018

Well, this was a surprising development. But let's not overreact.

How about we define what we want to have in a potential new hosting platform that we would migrate to? For me that would be:

important

  • import of
    • code
    • issues
    • pull requests
    • comments
  • export functionality (so we can switch the platform again if necessary and possibly make automatic backups every week or so)
  • working CI functionality

nice to have

  • github login for easy transition
  • sending PRs via e-mail (@opendata26) :)

Regarding working CI functionallity: as @z3ntu mentioned, Travis won't work out of the box, so we should adjust our scripts in a test repo and make sure that they work as expected before making the move.

From what I can tell, gitlab offers all of them in theory. But I'm not sure if the export is enabled for gitlab.com or whether we can automate that.

What do you think?

@ollieparanoid ollieparanoid reopened this Jun 4, 2018

@PureTryOut

This comment has been minimized.

Contributor

PureTryOut commented Jun 4, 2018

I agree that we should not overreact, but in my opinion the Microsoft acquisition is just (should be) the last push. Yes the entry barrier is low with Github, but it's a proprietary service for a completely FOSS project, it's in our case honestly even a bit hypocritical (in my opinion).

Gitea also offers them all, but like Gitlab doesn't have Travis. It does however support CI in general, and from what I see at least Drone supports it.

So, I'd think we have 2 choices. One:

  • Self-hosted
  • Non self-hosted

Two:

  • Gitlab
  • Gitea

I don't mind either, as long as it's FOSS and at least can be self-hosted for if we decide to later on.

@daveloyall

This comment has been minimized.

Contributor

daveloyall commented Jun 4, 2018

Regarding GitLab vs Travis-CI, I've opened this Issue travis-ci/travis-ci#9702

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Jun 4, 2018

Relevant quote from @bhush9:

KDE community would be happy to host and provide infrastructure to postmarketOS on our git ;)
We have our own custom gitolite based setup and for reviews we have phabricator

@bhush9

This comment has been minimized.

bhush9 commented Jun 5, 2018

FWIW, I see that gitlab free account is VERY limited compared to what Github free account provides.

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 5, 2018

@bhush9 looking through it seems most of the missing features we don't use anyway and stuff like squash and merge is free if we go the self hosted route

@bhush9

This comment has been minimized.

bhush9 commented Jun 5, 2018

See : https://about.gitlab.com/pricing/

Even for self-hosted, it comes with pricing.

@z3ntu

This comment has been minimized.

Member

z3ntu commented Jun 5, 2018

I just saw

Restrict push and merge access to certain users

on that pricing page in the paid section. We currently use that in this repo and it's very useful imo.
And as @opendata26 said, squash and merge is also not free (but also not in the self-hosted version, see https://about.gitlab.com/pricing/self-hosted/feature-comparison/)

@PureTryOut

This comment has been minimized.

Contributor

PureTryOut commented Jun 5, 2018

Even simple stuff like "Multiple approvals in code review" (which we use) seems to be lacking in the free version, if I'm understanding right that "Core" is what you get in the free variant. Honestly, looking at Gitlab more and more, it seems like a downgrade...

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 5, 2018

@z3ntu it is, look at specific wiki pages

I think we need someone who uses gitlab community already to comment on this

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 5, 2018

Oh

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 5, 2018

This is only if your project is private, if it's public all gold features are enabled for free.
Also, squash mr are free in community edition.

See https://about.gitlab.com/2017/09/01/gitlab-com-paid-features/#what-about-public-projects

@daveloyall

This comment has been minimized.

Contributor

daveloyall commented Jun 5, 2018

This PR piece is related to the "public project gets stuff free" issue: https://techcrunch.com/2018/06/05/gitlabs-high-end-plans-are-now-free-for-open-source-projects-and-schools/

Please note that even if, as a public project, we get some features at no cost, as I understand it, we do NOT get the source code for those features. Gitlab is "open core", not "libre software". The hardcore Free Software supporter in me does not like that. (But, I'm no BDFL! :) )

@MartijnBraam

This comment has been minimized.

Member

MartijnBraam commented Jun 5, 2018

Actually you still get the source for the enterprise features but the licence is propriatary

@craftyguy

This comment has been minimized.

Member

craftyguy commented Jun 5, 2018

@ollieparanoid

per your gitlab checklist, here's the second bullet: postmarketOS/pmbootstrap#1539

I haven't started on osk-sdl's CI yet, but that should actually be a bit easier than pmbootstrap's CI stuff :)

@kskarthik

This comment has been minimized.

Contributor

kskarthik commented Jun 7, 2018

So, what's the conclusion for this? Are we moving away from github or not ?

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Jun 7, 2018

It seems like Phabricator doesn't have as good import capabilities.

From what I can tell, people seem to be in favor of moving to gitlab and I'm as well. After some more researching: we can actually do exports from the API. That's an important advantage over GitHub besides having a (mostly) open source platform.

Sources:

Also I was curious of the issue ID remeains the same to ease the migration, and it does:

  • https://github.com/craftyguy/networkd-dispatcher/issues/39
  • https://gitlab.com/craftyguy/networkd-dispatcher/issues/39

This is how it looks like if the user doesn't have their GitHub account connected to their gitlab account:

(I'd prefer if it said "GitHub import" instead of an user name, maybe we can get that working as well.)


My proposed timeline:

  • Saturday, 2018-06-09: one year blog post
  • Tuseday, 2018-06-??: gitlab CI PR finished and testing should be done (otherwise delay dates below)
  • Wednesday, 2018-06-13 after CI is ready: announce github migration on the blog (so people can connect their gitlab and github accounts for a smoother migration)
  • the following weekend: do the migration

EDIT: The blog post is basically written (see open PR), but we need to delay it until CI is figured out. Updated schedule above accordingly.

@daveloyall

This comment has been minimized.

Contributor

daveloyall commented Jun 8, 2018

re: missing name on "merged by" field, I opened this ticket: https://gitlab.com/gitlab-org/gitlab-ce/issues/47619

@Halamix2

This comment has been minimized.

Halamix2 commented Jun 8, 2018

Importing from Google Code to Github worked the same, name of the original author was added to the post itself

@z3ntu

This comment has been minimized.

Member

z3ntu commented Jun 14, 2018

What's the plan for the repositories on GitHub? Will they stay?

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Jun 14, 2018

Yes, I would keep them. Because we have a lot of links to the existing issues and pull requests, and if we keep them they don't become invalid (maybe we can add a nice message on top of each issue with a script, that they have been moved).

Regarding code, someone mentioned that we could use the mirror feature of gitlab for that. But I think it would be better to archive the project, so people can't create new pull requests here. Opinions?

@bhush9

This comment has been minimized.

bhush9 commented Jun 14, 2018

I'd say a mirror makes more sense to not break people's existing forks ;)

Since git is de-centralized, it's not extra effort to just push to two different remotes or use GitHub mirror functionality, as for the pull requests, you can use NoPullRequests bot or as such to auto close them with response to move to GitLab

@craftyguy

This comment has been minimized.

Member

craftyguy commented Jun 15, 2018

I think we'd want to archive the repos here, if they're just mirrored then we will have people trying to file new issues, PRs, etc here and not in gitlab. If you need proof, look at the linux kernel mirror: https://github.com/torvalds/linux/tree/master/kernel

Everyone knows that merge requests for the kernel are not done through github.com PRs.. and yet there are 206 PRs that people have submitted! We could have some auto-reply thing like they do in that repo instructing folks to go file their thing on gitlab, but that just adds unnecessary complexity and will be yet one more thing to maintain by someone.

@MayeulC

This comment has been minimized.

MayeulC commented Jun 15, 2018

@craftyguy I don't think we can compare to the Linux kernel in terms of size and notoriety. There might be the odd pull request opened every now and then, but that's probably manageable on a case-by-case basis. We could also disable pull requests and issues altogether (I think we should).

In any case, the README should clearly state where development is happening, and I think it would be better to leave a mirror here.

@z3ntu

This comment has been minimized.

Member

z3ntu commented Jun 15, 2018

Issues can be disabled but PR's can't.

@opendata26

This comment has been minimized.

Member

opendata26 commented Jun 15, 2018

Yeah, archiving would make pre sense, amd it shouldn't break forka

@craftyguy

This comment has been minimized.

Member

craftyguy commented Jun 15, 2018

@MayeulC
my point is, that if people are still trying to use github for the linux kernel, which is wildly popular and has been following the same non-github process for development for decades, we cannot possibly hope that people will suddenly not try to file issues on github for this relatively new and unknown project :)

I suspect that this github site will show up higher in search rankings than the gitlab one (when it is made, at least for a while), further encouraging folks to file issues here and not on github.

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Jun 16, 2018

Personally I'm fine with breaking compatibility here. We can add a commit to the GitHub branch after the move, that prints out that pmbootstrap from GitHub is obsolete when trying to start it, and ask them to update their branch mappings (pointing to a pmOS wiki page, so we can have up to date information there even after we possibly moved away from gitlab to a self hosted instance in the future). Then we don't need to worry about legacy systems we keep syncing to (even if it does not seem like much effort, these kind of things build up and suddenly they are).

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Jun 17, 2018

Move to gitlab delayed some more until the CI stuff is figured out.

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Jun 27, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.