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.
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.
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.)
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.
In 2010, when Openstack has had its first release, Github already hosted 1 million repos. https://github.blog/2010-07-25-one-million-repositories/
For comparison: Sourceforge had less than 250,000 in 2010 https://en.wikipedia.org/wiki/SourceForge#/media/File:SF.net....
walking is an alternative to taking a car for short distances, even though walking as a mode of transportation clearly came first.
Some features I would like to see is ranking of repos by popularity, e.g. "Github stars".
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".
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?
Your assertion is correct that most organizations operate this way.
However, open source is different. Often you’ll have someone fork - hack on it - devise a novel change - and request a PR from their fork:branch to origin:branch.
In this scenario, the fork - and subsequent hacking - are exploratory while submitting the change and PR is distinctive. Not sure how one is supposed to explore and hack and provide PRs in their model as you’re forced to branch. A local copy is still a “fork” but with a separate origin.
You can still do a dual origin setup or do a merge main onto yours but I find this extremely limiting to contributors and overly controlling by project owners. There’s nothing stopping you from enforcing squash on merge or having standards on your SDLC. Enforcing that on everybody else isn’t in our best interest though. A diarrhea of commits is how you end up with spaghetti code.
On OpenDev, your clone/fork/personal branch is only on your dev machine and you only push patches, if I'm reading it right.
I guess the OpenDev model discourages people from forking the repo, modifying it to suit their needs, and then not sharing the results. To some degree.
I think I actually prefer the GitHub model where people's branches/changes are public by default unless they choose to go through the trouble to make their fork private. I have found many good bug fixes and enhancements for repos abandoned by their upstream authors this way.
It's a very subtle distinction, but having worked on OpenStack in the past, I much prefer the Gerrit model. Patch revisions are much easier to track over time than pushes to a PR branch during review.
OpenStack uses opendev, so anyone who wants to contribute upstream to openstack will need to know about the opendev ecosystem, possibly by dogfooding tools like Gerrit and Zuul in their own infrastructure.
I don't think openstack will go away any time soon, and I don't think they'll stop using Gerrit etc any time soon, so everyone else in their vicinity also remains encumbered with tooling that sometimes feels legacy or over-complicated :)
Personally, I don't mind gerrit as a code submitter and code reviewer. The workflow feels pretty straightforward to me. Some aspects of Gerrit administration are annoying though. It also seems a bit encumbered by being written in java; this flows on to annoyances like not supporting FIDO2 keys yet, and probably not in the near or medium future either (correct me if I'm wrong).
OpenStack is a large, complex piece of infrastructure software used at scale that many people, even on HN, will never experience directly. Why don't you hear about us much? Because people running at that scale frequently don't enjoy talking about the details of their infrastructure.
Ask the question next time you see something in a software tool, e.g. gerrit, that seems over-complicated: What can this software do because of this complication that I'm missing?
I don't think the tooling we use is what everyone should use, by any stretch, but don't assume things are being done in an antiquated way just because they're different than you're previous experiences or because they've been done that way for a long time.
Anyone can propose changes to practically all of the infrastructure via the https://opendev.org/opendev/system-config project.
Anyone can look through all of the changes; https://review.opendev.org/q/project:opendev/system-config+s...
Every change gets run through an extremely thorough CI system that tests the change and reports results, e.g. https://zuul.opendev.org/t/openstack/buildset/50ce144851224b...
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. http://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b62... is from a job that was modifying the gita deployment.
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 https://www.youtube.com/watch?v=apLHQ4DkIHU
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.)
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 https://zuul.opendev.org/t/openstack/builds?job_name=infra-p..., and every job has an artifact that lets you download the logs; e.g. https://zuul.opendev.org/t/openstack/build/c76ec695d19a4e9e9.... Details are at https://docs.opendev.org/opendev/system-config/latest/open-i...
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)
