It’s possible but:
- Is effort to implement that’s probably better spent on other things.
- Is effort to maintain (ex: monitoring to prevent spam).
1 Appreciation
Maybe we want the ends-justify-the-means case of using GitLab.com in order to actually get the EE functions. As much as we dislike that they are proprietary, they are substantially useful to us. Examples:
- multiple issue boards per repo
- marking epics, roadmaps
- multiple assignees for issues
- issue weighting
- marking related issues
- more…
The fact is, we simply have a rougher, more costly, more painful project management experience without some of these tools, even though we can make it work. Using them locks us in somewhat more, but there’s still the ability to export issues. Can they then be imported, i.e.g can we escape the EE version and move back to CE (or a fork of it) at a future time as a fallback? If not, I suspect GitLab folks will be receptive to requests for such fallback guarantees as they have been pretty sensitive and responsive to software-freedom requests, short of actually freeing their proprietary features fully…
All in all, I’m leaning pretty strongly toward GitLab.com at this point. I welcome push-back if anyone opposes this direction.
P.S. With more people moving to GitLab since Microsoft’s acquiring of GitHub, it potentially means that many more potential contributors will just already have GitLab.com accounts…
2 Appreciations
Some blockers we’d like fixed before we moving to GitLab.com:
- they use proprietary Google CAPTCHA for registration with broken fallback
- see https://gitlab.com/gitlab-org/gitlab-ce/issues/46548 (please upvote if you have an account there)
- they have some real GDPR compliance problems currently (their terms have a lot of agreeing to excessive things without meaningful consent or the ability to use the service without consenting to unnecessary things)
- https://gitlab.com/gitlab-org/gitlab-ce/issues/46888 among other issues (not all tracked yet probably)
Don’t know if you’re aware of it, but Web Architects run a GitLab CE instance aimed at co-ops: https://git.coop/
It could be a reasonable compromise between self-hosting and GitLab.com ?
edit: may not be suitable given the join-the-coop requirements for getting an account.
1 Appreciation
As a co-op, we are dedicated to working with and supporting other co-ops, so the idea is appropriate enough. But I doubt we’ll actually decide to go for that for various reasons.
Incidentally, we were aware, and git.coop is listed at https://wiki.snowdrift.coop/market-research/flo-repos#flo-source-hosting
(Is it actually the case that all volunteers would need to join the co-op just to have accounts? That would be a no-go for us, and we should perhaps clarify that in the wiki page too for others’ reference)
Issues with Gitlab EE notwithstanding, I still think we should make the move.
I would like to start planning for this. Are there any objections?
3 Appreciations
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…
1 Appreciation
Reminder that the first principle of sociocracy is government by assent, not consent. 
In other words, if people have an objection, they should let me know. Otherwise the plan shall move forward.
3 Appreciations
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 Appreciation
@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 Appreciation
Two updates:
-
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”
-
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 Appreciations
@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 Appreciation
@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.