- Free Software Needs Free Tools
-
+ 
OpenDev is a space for collaborative Open Source software development.
-OpenDev’s mission is to provide project hosting, continuous integration tooling, - and virtual collaboration spaces for Open Source software projects. OpenDev is - itself self hosted on this set of tools including - Code Review (Gerrit), - Continuous Integration (Zuul), - Etherpad, - Wiki (mediawiki), - Code Browsing (gitea) and so on. - This means that OpenDev itself is run like an open source project, you - can join us and help run the system. Additionally all of the services we run are - open source software themselves. The configuration for this site lives - here!
+What is Opendev?
+OpenDev is a space enabling collaborative Open Source +software development at a huge scale. It is centered around code hosting, +code review, and continuous integration, provided exclusively through +open source solutions like Git, Gitea, Gerrit and Zuul. It also provides +a number of peripheral collaboration services (like an etherpad instance for +collaborative text editing). All Opendev services are openly operated by the +Opendev community, and continuously integrated and deployed using Opendev +itself.
-Current Status
+How is development different with Opendev
+Opendev is not using a pull request (or merge request) +workflow, as implemented by GitHub or Gitlab. It follows a change proposal +workflow, which results in a slightly different experience.
+In a pull request workflow, contribution starts by +forking the original repository to your personal repositories, cloning that +repository locally, iterating on development while pushing commits to the +remote repository regularly... until your code seems ready to merge, at +which point you ask the service to create a pull request between your branch +and the original repository. The pull request is reviewed, and if accepted +your changes get merged into the original repository.
+In Gerrit, contribution starts by cloning the original +repository locally. You iterate on development, then use git push (or the +git-review tool) to propose your change to Gerrit. The change is reviewed, +and if accepted your change gets merged into the original repository.
+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 +model, you prepare a change, and propose it. You do not create a fork and +everyone contributes to the same original repository. It generally results +in less fragmentation, and avoids confusion between the original repository +and its numerous forks.
+That high-level difference also affects lower-level +details. A pull request may contain several commits, and if merged all those +commits will appear in the original repository history. In Gerrit, every commit +will result in a separate change for code reviewers to review, so developers +usually squash commits created while developing but which do not help +reviewers understand the proposed change. It generally results in easier +code review, and a cleaner git log as meaningful commit messages are +reviewed as part of the change.
+In summary, the Gerrit workflow, its user experience +and UI are different from the pull request workflow. While it may not be +immediately familiar to developers used to pull request workflows, it's +worth learning. Its long-term benefits outweigh the short-term drawback +of having to learn a new tool, especially if you are going to spend a lot +of time developing for that project anyway.
-We are still early in the process of building this out.
-Most of the services we run were inherited and rebranded from the - existing community run OpenStack Infrastructure. This means that while we do already - have many services running, there may still be some services branded as "OpenStack" while we complete the rebranding.
+Integrated Continuous Integration
+One key benefit of Opendev is that it integrates +powerful continuous integration features, made possible by the donation of +compute resources from our infrastructure partners. Test jobs are +run when changes are proposed and provide code reviewers with valuable +information. Test jobs also run again at merge-time, in case recently-approved +changes introduce an incompatibility. This, combined with the fact that +changes must pass tests before they can be approved, prevents +merging broken code.
+Advanced Zuul features like speculative execution of +tests allows changes to test in parallel, so development velocity is +never limited by how thorough you want your tests to be. Changes in one git +repository can depend on proposed changes in another repository, allowing +integration testing of features actively developed across multiple projects, +removing artificial barriers between development teams.
+This advanced continuous integration system was +developed to sustain the complexity and scale of OpenStack development, one +of the 3 most actively developed open source projects in the world. Opendev +makes this system available to other projects -- enabling open development +at a huge scale for everyone.
-Join Us
-As mentioned previously the OpenDev services themselves are open source software managed on top of OpenDev itself. This means that in addition to using OpenDev to host your software development activities you can help us run OpenDev with all of the same tools.
-If you use the system and find it useful, we’d love to have your help running it as well.
+Free software needs free tools
+Finally, another key difference between Opendev and +other development infrastructure services like GitHub or Gitlab.com is that +it's built purely using open source software. GitHub and Gitlab.com are free +to use for open source projects, but they are both using proprietary code. +If your free and open source software requires proprietary code to be built, +is it really free?
+It is widely-accepted today that using open source +technology in your software stacks reduces your dependency to third-parties +and allows to spread innovation. It should be obvious that writing software +using open source technology has the same effect. Nothing prevents a service +provider from changing its service terms, creating new limitations or even +fully excluding your project, or contributors from specific countries. +Proprietary development services create the same form of hard limits, lock-in +and dependency than proprietary software does, and prevent open innovation +in the development infrastructure space.
+Opendev is entirely built using open source software, +but goes one step beyond: it is also openly operated. All its operation and +configuration is also open source, lives in git, and is continuously-deployed. +In the spirit of open source, it is easy to study, replicate, modify and +redistribute. Like free and open source software, it requires engaging with +its community to get the most of it -- it's not a service you consume, it's +a community you join. That can be a bit overwhelming if you just want to +focus on development, especially when ready-to-consume services are +available. But it's worth it, especially if you want to have a say on what +services are provided, or just support the idea of improving open source +tools in that space.
-FAQ
+FAQ
-Isn’t this just OpenStack Infrastructure rebranded?
-It is more than that. We want to make this toolset available to others that would find it helpful. OpenStack is one of the OpenDev tenants, but other tenants like Zuul or $gizmo would be just as important.
+Isn’t this just OpenStack Infrastructure rebranded?
+It is more than that. We want to make this toolset +available to others that would find it helpful. OpenStack is one of the OpenDev +tenants, but other tenants like Zuul or $gizmo would be just as important.
-Can I host my project on OpenDev?
-Yes! However, as noted above it is still early days yet and the early experience might be a bit bumpy. Certain things may still say “OpenStack” on them as we figure out the transition. And while any moves should come with appropriate redirects, we may have some inadvertent misses.
+Can I host my project on OpenDev?
+Yes! However, as noted above it is still early days yet +and the early experience might be a bit bumpy. Certain things may still say +“OpenStack” on them as we figure out the transition. And while any moves should +come with appropriate redirects, we may have some inadvertent misses.
-Can I run tests on Windows or OSX machines?
-Currently all of our test resources are Linux based. Adding additional platforms would likely require someone to help us get that running, but Zuul will support systems with ansible connection plugins. Talk to us!
+Can I run tests on Windows or OSX machines?
+Currently all of our test resources are Linux based. +Adding additional platforms would likely require someone to help us get that +running, but Zuul will support systems with ansible connection plugins. +Talk to us!
-I am an existing OpenStack Infra user do I need to do anything?
-No. We’ll continue to communicate changes as they happen. We’ll also do our best to make this as smooth a transition as possible. If we run into situations that force us to break something we’ll be sure to let you know at that point.
+I am an existing OpenStack Infra user do I need to do anything?
+No. We’ll continue to communicate changes as they +happen. We’ll also do our best to make this as smooth a transition as +possible. If we run into situations that force us to break something we’ll +be sure to let you know at that point.
-Is a CLA required for hosted repos?
-No.
+Is a CLA required for hosted repos?
+No.
-What if I don’t like Gerrit and would prefer (insert tool here)?
-We’ve got a fair bit of experience with the existing toolset and adding new tools for which we’ve already got an answer is currently out of scope. We think the existing tools (like Gerrit) work well, and should only get better as we update them. The system is able to scale because we do not need multiple implementations of different software that solve similar problems.
+What if I don’t like Gerrit and would prefer (insert tool here)?
+We’ve got a fair bit of experience with the existing +toolset and adding new tools for which we’ve already got an answer is currently +out of scope. We think the existing tools (like Gerrit) work well, and should +only get better as we update them. The system is able to scale because we do +not need multiple implementations of different software that solve similar +problems.
-Why can't we use Gitea's issue tracker and wiki?
-For scaling and redundancy purposes we are actually running a number of independent Giteas behind a load balancer. We can keep git repos in sync from Gerrit reasonably well, but the issue tracker and wiki functionality would need another level of state syncing. Once Gitea can be run as a proper cluster this may change, but until then the functionality is limited.
+Why can't we use Gitea's issue tracker and wiki?
+For scaling and redundancy purposes we are actually +running a number of independent Giteas behind a load balancer. We can keep +git repos in sync from Gerrit reasonably well, but the issue tracker and +wiki functionality would need another level of state syncing. Once Gitea +can be run as a proper cluster this may change, but until then the +functionality is limited.
-