So time for a history lesson.<p>First, who am I? I'm JayF -- I've been working on OpenStack for about a decade, and am the currently serving TC Chair. This is not an official history, but my attempt to give you the story behind this from my perspective.<p>OpenDev collaboratory originally started as part of OpenStack itself -- as the team that enabled us to test the giant software suite. When it became clear that the tooling created and used by that team had general interest, it became time for them to spin off into their own group. I'll note that this maps similarly to what happened with Zuul -- a tool created around OpenStack, that was generally useful and split into it's own project. OpenDev was infrastructure services created around OpenStack and for OpenStack, that are generally useful and split into it's own project.<p>This context is important as to where it puts things on the timeline: OpenDev, and the associated technologies, were not created as an alternative to some incumbant power like Github or Gitlab -- when it was created, there were few, if any, other tools that could operate at that level of scale. (It's unclear to me if Github, as we think of it today, even existed or was at any level of popularity at this point in time.)<p>So as this thread hopefully picks up steam, lets avoid terms like "alternative to" or things that miss the context. OpenDev has been around, and open, for a long time. It will continue to be around, and open, for a long time. They aren't going to feed your code into an AI to train it, and they aren't going to try and turn your collaboration toolset into a social media platform. It's a tool to get work done, and I've been lucky to work in it for the last ten years.
The UI is much faster than Github, which is great, big selling point for me. The "iterative change" approach is pretty much how companies use Github I think. Contributors are given push permissions for the repo, the main branch being off limits, and PRs are required an approval before they can be merged. The Github model with forks is not great imo, because forks get out of sync pretty immediately.<p>Some features I would like to see is ranking of repos by popularity, e.g. "Github stars".
> <i>The difference is subtle, but significant. In the pull request model, you create a fork of the original repository, push changes to it, and ultimately propose to merge changes back. In the change proposal model, you prepare a change, and propose it. You do not create a complete fork and everyone contributes into the same original repository with what are basically lightweight, ephemeral topic branches</i><p>This is an odd distinction to make. Forking in GitHub is an entirely optional process - in my experience it's primarily used to invite outside collaborators to open source projects. I've never worked on a team that uses this process for their owned repos. I've only ever used GitHub Pull Requests according to the process described here as the "Gerrit way".<p>I've never used Gerrit so not sure if I'm missing something here: it sounds like they're just describing a process that works identically to PRs with the exception that the platform doesn't support forks?
Some of the folks running this (of which I am one) are going to be talking about it in a livestream in a little over a week: <a href="https://openinfra.dev/live/" rel="nofollow">https://openinfra.dev/live/</a>
This seems to be squarely aimed at Gerrit fans, which is difficult for me to wrap my head around. The projects I'm on which are Gerrit-encumbered all seem to regard it as a necessary evil rather than a selling point. Still, the project is well-thought-out and I hope it's successful!
One of the most interesting parts of OpenDev is that the infrastructure that builds and deploys all the OpenDev services is open.<p>Anyone can propose changes to practically all of the infrastructure via the <a href="https://opendev.org/opendev/system-config" rel="nofollow">https://opendev.org/opendev/system-config</a> project.<p>Anyone can look through all of the changes; <a href="https://review.opendev.org/q/project:opendev/system-config+status:open" rel="nofollow">https://review.opendev.org/q/project:opendev/system-config+s...</a><p>Every change gets run through an extremely thorough CI system that tests the change and reports results, e.g. <a href="https://zuul.opendev.org/t/openstack/buildset/50ce144851224b239db62aee74a472bd" rel="nofollow">https://zuul.opendev.org/t/openstack/buildset/50ce144851224b...</a><p>Most of these CI jobs do things like apply your proposed change, deploy the service, then connect up a headless client and take screenshots of the results so you can confirm the correct behaviour of your change; e.g. <a href="http://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_9e6/905020/1/check/system-config-run-gitea/9e618c2/bridge99.opendev.org/screenshots/" rel="nofollow">http://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b62...</a> is from a job that was modifying the gita deployment.<p>Humans approve changes for merge with Zuul, but Zuul commits the code. When Zuul merges the change, another set of jobs will push things to the production hosts automatically. There is a talk on the overall process at <a href="https://www.youtube.com/watch?v=apLHQ4DkIHU" rel="nofollow">https://www.youtube.com/watch?v=apLHQ4DkIHU</a><p>There are obviously bastion hosts and private components to the production deployment, but as much as practical is completely open. There have been contributors with no special access that have developed the deployment of infrastructure services and admins helped only at the end committing some secrets and providing production hardware resources. More commonly, people who have CI issues can jump in and fix their own problems, especially relating to things specific to them (e.g. mirror setup on CI nodes, software versions used, etc.)<p>One cool thing is that the Zuul jobs publish their production deployment logs in public, but encrypted (these might contain secrets, so are not made open by default). If you work on a particular system, you can request to commit your public key to the service you like and access all the deployment logs. For example, say you are interested in maintaining codesearch.opendev.org. The "infra-prod-codesearch" job deploys changes relating to this service. You can look at all the jobs at <a href="https://zuul.opendev.org/t/openstack/builds?job_name=infra-prod-service-codesearch" rel="nofollow">https://zuul.opendev.org/t/openstack/builds?job_name=infra-p...</a>, and every job has an artifact that lets you download the logs; e.g. <a href="https://zuul.opendev.org/t/openstack/build/c76ec695d19a4e9e9dc4a2dfd2f480d8/logs" rel="nofollow">https://zuul.opendev.org/t/openstack/build/c76ec695d19a4e9e9...</a>. Details are at <a href="https://docs.opendev.org/opendev/system-config/latest/open-infrastructure.html#deployment" rel="nofollow">https://docs.opendev.org/opendev/system-config/latest/open-i...</a><p>Wikimedia is the only other platform I've seen with a comparable commitment to open infrastructure (unsurprisingly there has been collaboration between the two over the years)