Setting up a gitlab instance for the social dot coop

[deactivated account] Public Seen by 290

I just barely missed the cutoff for voting whether or not we should buy shares to get access to git.coop, and was frustrated but not surprised to see that it passed in favor of buying the shares. while I think everyone can agree that we need to start hosting our code somewhere as we grow, my issue was that no alternatives were presented besides hosting it with git.coop (well, besides the implicit suggestion of github, but I don't think anyone wants to do that lol). since I'm a strong proponent of owning and controlling our own technical infrastructure, I'd like to present just such an alternative - hosting it ourselves!

I set up a fresh gitlab instance at https://git.socialcoop.frenchha.us with open registration, so please feel free to create an account and try it out. If people are interested in doing so, it wouldn't be hard to move the url over to git.social.coop, either. I'm not really sure how we'd go about deciding that, but I'm happy to keep hosting it if we decide we'd prefer to use git.social.coop over git.coop.


Danyl Strype Mon 11 Jun 2018

If you're willing to maintain this going forward (for now), and train some of us up on any of its essential weirdnesses, so we can help, and ensure succession when you want to step down as maintainer, I'm all in favour of making this an official social.coop thing.

On the process question, I suggest that we treat decisions made here as indications of rough consensus. Any decisions is always open to being reconsidered, to see if a new consensus emerge, especially when a new idea or fact comes up that wasn't considered when the original decision was made.
EDIT: fixed typos


Danyl Strype Mon 11 Jun 2018

Further to this, in response to a question someone asked in the 'buy a share' discussion (@wulee ?), I think it's always best to start with a proposal in this subgroup, and then if it receives strong support, escalate it to other subgroups (eg finance) as required. That way, we can second-guess ourselves like this, or by new suggestions or major amendments emerging as part of the first proposal process, without messing the wider group around ;)


Mayel de Borniol Mon 11 Jun 2018

Congrats on going ahead and experimenting!
I've copied our github repos to https://git.socialcoop.frenchha.us/socialcoop


Nick S Mon 11 Jun 2018

Sorry that your vote wasn't heard, @gregcerna. So I thought it was you I saw you talking about this on Mastodon and I attempted to invite you in to the vote (so many Gregs!), perhaps I didn't do it in time.

(Will say more when I get another moment)


Nick S Tue 12 Jun 2018

Why no alternatives?

It seemed reasonable to take the only proposal tabled at the time and try and get consent to go with it. I think there's some urgency to sort something out, and git.coop ticked a lot of boxes.

Decision period

I was unsure how long to set the decision period and left it at the default 3 days. In retrospect maybe it was too short. I set the the main group decision is longer at 4, and I think I'll extend it to 6 as per the social.coop bylaws which state this as the default; alternatively I could label it "URGENT" but there may be some discussion to be had and I'd rather not be seen as jumping the gun.


Thanks for setting this up and generously offering to let us use it. I may try it in the interim as you propose, to start filing issues.

A couple of questions:
- I gather migrating GitLab only works (easily) between instances of the same version. Is yours the same version as https://git.coop?
(I gather GitLab is meant to state its version in the help page, but https://git.coop/help does not seem to. You may want to check with Web Architects and/or @chriscroome)
- I don't think you say what it's hosted on (from the POV of resilience, security etc), nor what features you've deployed. Can you write something which compares and contrasts your deployment with http://git.coop?
e.g. Does it allow CI with Docker, etc.? (Ditto)


There are some plusses to deploy-it-yourself, but just to be on the level, here are some reservations I have about using your deployment for more than just a stop-gap:
- Are you offering to host this?
- If so, doesn't that mean this isn't social.coop infrastructure, it's yours?
- Are you the only admin?
- If you get hit by a metaphorical falling piano will we be able to recover this infrastructure?
- Or if social.coop will own and run the host collectively, does this mean a subscription to authorise?
- What tasks would we need to add to our admin rota? (Backups, updates, troubleshooting, etc.)
(i.e. We're short of admin power right now, and not especially flush with money.)

The benefit of using git.coop

We're in a situation with just two admins who have day jobs and want to hand over ASAP. I endorse "owning and controlling our own technical infrastructure" however under these circumstances we probably want to keep it as simple as possible. With git.coop:
- We're not hosting it (no recurring fees)
- We're not maintaining it (doesn't add to our workload)
- It's not on our production servers (stays up if they go down)
- It's super value for money (the one-off share purchase is small)
- It's a share not a fee.


Matt Noyes Tue 12 Jun 2018

I would add that we need to solidify our own status as a cooperative before hosting (reservations raised by Nick are related) and there is a benefit from establishing a connection with another platform cooperative.


Matt Noyes Mon 11 Jun 2018

I think our priorities are: secure, stable, reliable hosting; democratic ownership, governance and admin; education and sharing of skills; and building the co-op ecosystem. So we should either own and control the hosting ourselves -- which means owning it as a coop -- or we should collaborate with a co-op hosting service.