In initially discussing GitLab.com vs git.snowdrift.coop I thought there were jut pros and cons but we could live with just our one instance. However, it turns out that we currently use GitLab Pages for our design prototyping process, and git.snowdrift.coop cannot use Pages, we have a repo at framagit.org/snowdrift.
UPDATE: GitHost is going away in a year anyway, so that option is out.
To consolidate and for the future, we have these options:
- [probably not this] self-host GitLab CE, take responsibility for all sysadmin stuff and hosting costs, but we get GitLab Pages and could eventually figure out single sign-on within our ecosystem
- [unlikely] find another free GitLab hosting service that would do everything we have now but work with GitLab Pages
- move to GitLab.com and accept that it’s EE (proprietary edition), and while people may have accounts and can use GitHub and other options, no SSO with our system, and less full control over our setup
- move everything to Framagit’s instance, relying on them, not sure what trade-offs
On the last option, we want to develop more partnership and communication with Framasoft anyway. They are one of the primary software-freedom organizations out there whose work we’d love to include at Snowdrift.coop. Are there many downsides the moving to Framagit entirely? Maybe we should open communication with them first?
more on how we use GitLab Pages
The core issue relates to working out this workflow:
- Designers do their user-stories, wireframes, mockups
- Prototypers build HTML/Sass stuff per that repo linked above and can see it live and share it publicly with the designers and others
- There should be a code review of the protoype HTML/Sass before it is handed off to haskellers to implement on the live Snowdrift.coop site in Hamlet etc.
- Then, a code review of the final work before merging and deploying
This process itself needs to be finalized and documented, but we’re almost through a first iteration of this for new design stuff.