Githost going away. Choose GitLab.com, Framagit, or self-host?

At this point, I don’t see any other option being truly superior. So, I think all the trade-offs point toward going forward with GitLab.com. I see the EE issues as themselves being mixed because while they are proprietary, we will actually benefit from using them.

I think planning the move at this point makes sense. There will be several things to think through.

That said, I’d like to get consent from the rest of the team and hear out any push for framagit (I have sympathies to the idea of going with them if we talk to them and they want us).

P.S. chatted with GitLab folks at OSCON this week

… discussed how I see them as the very best of the projects that are still in the wrong overall club (the most FLO, ethical, ideal of the non-fully-FLO VC-backed stuff). Suggested to them to consider being a Benefit Corp. Person told me that their goal is to have an IPO as their exit for the VC investors and they see a buy-out as the worst case.

Aside from the other various FLO issues (which I acknowledge as a matter of economics), it’s the VC obligations that are the most troublesome. Both an IPO or a buyout (and the influence of the VC investors now) mean pressure for GitLab to sell out their values even if they could be profitable otherwise. If they were a Benefit Corp, they’d be more tied to making profit without compromising their core values… I may contact Sid and push this issue specifically…

Reminder that the first principle of sociocracy is government by assent, not consent. :slight_smile: In other words, if people have an objection, they should let me know. Otherwise the plan shall move forward.

3 Likes

I made a “milestone” in our private ops repo where we can track multiple issues in the process of moving to GitLab.com — those who have access can check that out and potentially add issues there (although we should continue related general discussion here on the forum)

Quick update: we’re potentially proceeding with the GitLab.com migration 2018-12-23T15:00:00Z. This will take a few hours, and we’ll post here again when we’re done.

Drop by our IRC channel/Matrix room if you need help or have any questions. Thanks!

1 Like

@team We will be starting this very soon, please stop using git.snowdrift.coop, and we’ll update here when we’re set up on gitlab.com

We were able to migrate most repos, but the design and code repos failed to import. So, we are treating today as a test run and will continue using git.snowdrift.coop for the moment; once we’ve figured out the import issues, we’ll run the migration for real.

I suspect that the error has to do with the size of these repos. If that’s true, we should be able to ask the githost people for an export that omits stuff we don’t care about (example of how to do that here). I’ve sent an email to githost support, we’ll see what they say.

1 Like

Two updates:

  1. We’re waiting to hear back from GitLab.com about them doing manual migrations for us since there’s a bug in their auto-migrations. They can do it manually, we just are waiting to hear back from them after we said “yes, please do that”

  2. If we want to consider self-hosted GitLab CE still just for the principle of it (though it seems the answer is “no”), we could keep git.snowdrift.coop (the specific internal subdomain) and OSUOSL says they could host and maintain that for us… See https://community.snowdrift.coop/t/hosting-at-osu-osl/1319 — but that would have the issue of still managing spam user accounts (or ignoring but having them); but that’s an option if we really felt it was worthwhile.

For now, assuming we’re going ahead with GitLab.com still.

Is there any way of including gitlab with the single-sign-on?

Although it’s not impossible, I don’t think SSO with GitLab and Snowdrift.coop is straightforward, and it probably would require staying with our own instance (there’s no way GitLab.com is going to start supporting Snowdrift.coop log-in).

Short story short, there is an import bug and the gitlab folks are going to do the import manually for us to work around it.

@team I plan to generate the exports and start the migration today at 23:59 PST (approximately 15 hours from now). While you can continue using git.snowdrift.coop after that point, nothing you do will be carried over to gitlab.com. I’ll ping everyone again when I begin the migration and when it is complete.

2 Likes

@team Exports have begun. Don’t expect anything you post after this point to be migrated! (Of course, you can still use git.snowdrift.coop after this point if you want, you’ll just have to re-create your activity on gitlab.com once the migration is complete).

@team The migration is complete, except the Design and Code repos, which we’re waiting on the gitlab folks to import (hopefully should happen later today). Still, you can start using gitlab.com/snowdrift for all other repos.

I believe all team members have been added to that group (and have the necessary permissions). If not, please let me know and I’ll fix that.

1 Like

@alignwaivers is not in the new member list (I pinged him to get that info for his account), otherwise all the core team is listed

Though not official team members, people we have given developer access to the group before include @CANAWEN , @thomasj10 , @victor (I think that’s Tuxayo’s nick here), and two who have not yet made forum accounts: Nicholas Montaño @montanonic and Peter Harpending @pharpend , people who we may want to reach out to soon to recruit them back if possible.

I also think we have some people who got access to specific projects without being group members.

All the tasks are assigned to “Snowdrift.coop Import” user rather than the appropriate person, so until that is updated (manually? And is that up to us to do or they are doing it?), we don’t have any of the assignments correct.

Some of our labels (the group level ones?) seem to be missing too.

Yes, I think so.

This makes sense because the repos were imported individually; there’s not a way to migrate the whole org as far as I know. I wonder if I added the labels at group level and re-did the import, would they be applied?

Think that they’ll do the assigning, or we do it?

I think it’s fine to just understand what the state of the migration is and then do grooming (which is good to do anyway) to update all the labels.

erp. tired. edited. ok on just proceeding as-is.

Could you ask them: besides the code and design repo migrations, what we should expect them to do (labels and assignments or anything else) versus adjust manually ourselves?

The code and design repo migrations are the only things I’ve asked them to do.

1 Like

Status update: The migration is effectively complete.

https://gitlab.com/snowdrift/ops/issues/41 tracks the tasks, and the remaining ones currently are:

  • setting up CI/CD for the main site (currently, we have no way to build or deploy)
    • this is related to losing a server we had been using, not just to the GitLab migration, so resolving this probably involves finishing our systems migration to OSUOSL as well
  • making git.snowdrift.coop urls redirect to gitlab.com/snowdrift
  • writing a blog post about this migration

But for all other purposes, the migration is done and everyone should be using GitLab.com now to engage with our issues and code etc. (although if anyone has an issue with that, we will do what we can to accommodate).

1 Like