cf479002f9
These are copied verbatim from the main opendev.org splash page, as the initial step in an effort to shrink the content we display there. A couple of sections from that page have also been turned into additional questions. Change-Id: Ic5bdb9199fd9f9851e68a334045d157a21a137a3
141 lines
6.6 KiB
ReStructuredText
141 lines
6.6 KiB
ReStructuredText
:title: Frequently Asked Questions
|
|
|
|
.. _faq:
|
|
|
|
Frequently Asked Questions
|
|
##########################
|
|
|
|
How is development different with OpenDev?
|
|
==========================================
|
|
|
|
OpenDev doesn't use a pull request (or merge request) workflow, like
|
|
those implemented by GitHub or Gitlab. Instead it follows Gerrit's
|
|
iterative change proposal workflow, which results in a slightly
|
|
different experience.
|
|
|
|
In GitHub or Gitlab, contribution typically starts by forking a personal
|
|
copy of the original repository, cloning that locally, and pushing one
|
|
or more commits to that personal fork. Once your code seems ready to
|
|
merge, you ask the service to create a pull request for your branch into
|
|
the original repository. The pull request is reviewed, and if accepted
|
|
your changes get merged into the original repository. If not, you push
|
|
more commits to your fork and update the request seeking more reviews.
|
|
|
|
By contrast, contribution with Gerrit starts by cloning the original
|
|
repository locally. You iterate on development of one or more local
|
|
commits, and then use git push (or the git-review tool) to propose your
|
|
commits as a series of changes to the Gerrit code review service. Each
|
|
change in the series is reviewed, and if it's accepted (and passing
|
|
tests) then it gets merged into the original repository. If more work is
|
|
needed, you amend the same commits and push new versions of them for
|
|
re-review.
|
|
|
|
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. It results in less
|
|
fragmentation overall, 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
|
|
is a separate change (optionally depending on other related changes) for
|
|
code reviewers to review, so developers squash or amend edits made while
|
|
developing to represent the desired final state of that change. Each
|
|
prior revision of a change is still retained by the service, as are all
|
|
the review comments, so updates can be compared side-by-side for a clear
|
|
picture of how the change evolved. It generally results in easier code
|
|
review, but also a cleaner branch history with the commit messages
|
|
reviewed as an integral part of each 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. Long-term benefits outweigh the short-term cost of
|
|
having to learn a new tool, especially for someone who is going to spend
|
|
a lot of time developing for that project anyway.
|
|
|
|
What is the 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 generous 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, preventing code which
|
|
doesn't pass tests from merging to the repository.
|
|
|
|
Advanced Zuul features like speculative execution of tests allow the
|
|
testing of sequenced changes in parallel, so development velocity is
|
|
rarely 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 three most
|
|
actively developed open source projects in the world. OpenDev makes this
|
|
system available to other projects, enabling open development at scale
|
|
for everyone.
|
|
|
|
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 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.
|
|
|
|
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.
|
|
|
|
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.
|