#, fuzzy msgid "" msgstr "" "Project-Id-Version: contributor-guide\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2024-04-15 06:24+0000\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../../source/code-and-documentation/devstack.rst:3 #: ../../source/code-and-documentation/devstack.rst:150 msgid "Testing Changes with DevStack" msgstr "" #: ../../source/code-and-documentation/devstack.rst:5 msgid "" "An important part of development is, obviously, being able to test changes " "you develop and ensure that they function properly. In a complicated " "ecosystem like OpenStack there is a need to also be able to verify the " "interoperability of your code. You may make a change to Cinder but that " "change can also impact the way that Nova interacts with Cinder's APIs." msgstr "" #: ../../source/code-and-documentation/devstack.rst:12 msgid "" "Developers need an easy way to deploy an OpenStack cloud to do functional " "and interoperability testing of changes. This is the purpose of DevStack." msgstr "" #: ../../source/code-and-documentation/devstack.rst:16 msgid "What is DevStack" msgstr "" #: ../../source/code-and-documentation/devstack.rst:18 msgid "" "DevStack is a modular set of scripts that can be run to deploy a basic " "OpenStack cloud for use as a demo or test environment. The scripts can be " "run on a single node that is baremetal or a virtual machine. It can also be " "configured to deploy to multiple nodes. DevStack deployment takes care of " "tedious tasks like configuring the database and message queueing system, " "making it possible for developers to quickly and easily deploy an OpenStack " "cloud." msgstr "" #: ../../source/code-and-documentation/devstack.rst:25 msgid "" "By default, the core services for OpenStack are installed but users can " "configure additional services to be deployed. All services are installed " "from source. DevStack will pull the services from git master unless " "configured to clone from a stable branch (i.e. stable/pike)." msgstr "" #: ../../source/code-and-documentation/devstack.rst:32 msgid "" "DevStack's full documentation can be found `here `_." msgstr "" #: ../../source/code-and-documentation/devstack.rst:36 msgid "Getting and Configuring DevStack" msgstr "" #: ../../source/code-and-documentation/devstack.rst:38 msgid "" "To get DevStack you will need to clone it from the ``devstack`` repository " "under ``openstack``." msgstr "" #: ../../source/code-and-documentation/devstack.rst:45 msgid "" "It is recommended before proceeding further to set-up passwords and IP " "addresses for the environment in which you are running DevStack. This is " "done by configuring the ``local.conf`` file in DevStack." msgstr "" #: ../../source/code-and-documentation/devstack.rst:55 msgid "" "To simplify future interaction with your deployment you will want to set the " "following variables:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:58 msgid "ADMIN_PASSWORD" msgstr "" #: ../../source/code-and-documentation/devstack.rst:59 msgid "DATABASE_PASSWORD" msgstr "" #: ../../source/code-and-documentation/devstack.rst:60 msgid "RABBIT_PASSWORD" msgstr "" #: ../../source/code-and-documentation/devstack.rst:62 msgid "" "On some distributions you may need to also set the ``HOST_IP``. Whether this " "is necessary will depend on what naming convention is used for network " "interfaces in your operating system." msgstr "" #: ../../source/code-and-documentation/devstack.rst:66 msgid "" "Further down the file is the ``Using milestone-proposed branches`` section. " "These are the variables that can be changed if you wish to clone a branch " "other than master for one or more projects." msgstr "" #: ../../source/code-and-documentation/devstack.rst:70 msgid "" "Once your changes have been saved to local.conf you are ready to deploy an " "OpenStack cloud with DevStack." msgstr "" #: ../../source/code-and-documentation/devstack.rst:74 msgid "Deploying DevStack" msgstr "" #: ../../source/code-and-documentation/devstack.rst:76 msgid "" "Once you have your ``local.conf`` file configured executing DevStack is " "quite easy." msgstr "" #: ../../source/code-and-documentation/devstack.rst:81 msgid "" "The following command needs to be run as a user with sudo access and " "NOPASSWD configured." msgstr "" #: ../../source/code-and-documentation/devstack.rst:90 msgid "" "The above command and subsequent command examples assume you are still in " "the root directory of your DevStack clone." msgstr "" #: ../../source/code-and-documentation/devstack.rst:93 msgid "" "At this point DevStack takes over preparing your node to function as an " "OpenStack cloud. The following is done:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:96 msgid "Required packages (like mysql and rabbitmq) are installed" msgstr "" #: ../../source/code-and-documentation/devstack.rst:97 msgid "mysql and rabbitmq are configured" msgstr "" #: ../../source/code-and-documentation/devstack.rst:98 msgid "The OpenStack projects are cloned into /opt/stack/" msgstr "" #: ../../source/code-and-documentation/devstack.rst:99 msgid "" "Any temporary backing files needed to simulate a system are created in /opt/" "stack/data" msgstr "" #: ../../source/code-and-documentation/devstack.rst:101 msgid "Each project's database is created and populated" msgstr "" #: ../../source/code-and-documentation/devstack.rst:102 msgid "The OpenStack Services are registered and started" msgstr "" #: ../../source/code-and-documentation/devstack.rst:104 msgid "A log of the stack.sh run is kept in ``/opt/stack/logs/stack.sh.log``." msgstr "" #: ../../source/code-and-documentation/devstack.rst:107 msgid "Verifying Your DevStack Deployment" msgstr "" #: ../../source/code-and-documentation/devstack.rst:109 msgid "" "If OpenStack was successfully deployed by DevStack you should be able to " "point a web browser at the IP specified by ``HOST_IP`` in ``local.conf`` and " "access Horizon." msgstr "" #: ../../source/code-and-documentation/devstack.rst:119 msgid "" "The ``admin`` password will be set to the value you put in your ``local." "conf`` file for ``ADMIN_PASSWORD``" msgstr "" #: ../../source/code-and-documentation/devstack.rst:122 msgid "" "Project services are all registered with systemd. Each service is prefixed " "with ``devstack@``. Therefore you may verify through systemd that the Cinder " "Volume process is working with a command like:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:130 msgid "" "Since systemd accepts wildcards, the status of all services associated with " "DevStack can be displayed with:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:137 msgid "" "Logs for the running services are also able to be viewed through systemd. To " "display the logs for the Cinder Volume service the following command could " "be used:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:145 msgid "" "A more complete reference of using systemd to interact with DevStack can be " "found on the `Using Systemd in DevStack `_ page." msgstr "" #: ../../source/code-and-documentation/devstack.rst:152 msgid "" "Using DevStack to develop and test changes is easy. Development can be done " "in the project clones under ``/opt/stack/``. Since the " "projects are clones of the project's git repository a branch can be made and " "development can take place." msgstr "" #: ../../source/code-and-documentation/devstack.rst:158 msgid "" "DevStack uses the code in those directories to run the OpenStack services so " "any change may be tested by making a code change in the project's directory " "and then by restarting the project's service through systemd." msgstr "" #: ../../source/code-and-documentation/devstack.rst:163 msgid "" "Here is an example of what that process would look like. In this example a " "change is made to Cinder's LVM driver:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:173 msgid "" "Once testing and development of your code change is complete you will want " "to push your code change to Gerrit for review. Since the projects in ``/opt/" "stack`` are already synced to their respective git repository you can " "configure `git review `_, commit your change and upload the " "changes to Gerrit." msgstr "" #: ../../source/code-and-documentation/devstack.rst:181 msgid "Stopping DevStack" msgstr "" #: ../../source/code-and-documentation/devstack.rst:183 msgid "" "To shutdown a DevStack instance running on a node the following command " "should be used:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:190 msgid "" "This command cleans up the OpenStack installation that was performed on the " "node. This includes:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:193 msgid "Stopping the project services, mysql and rabbitmq" msgstr "" #: ../../source/code-and-documentation/devstack.rst:194 msgid "Cleaning up iSCSI volumes" msgstr "" #: ../../source/code-and-documentation/devstack.rst:195 msgid "Clearing temporary LVM mounts" msgstr "" #: ../../source/code-and-documentation/devstack.rst:197 msgid "" "Running ``unstack.sh`` is the first thing to try in the case that a DevStack " "run fails. If subsequent runs fail a more thorough removal of DevStack " "components may be done with the following command:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:205 msgid "" "A ``clean.sh`` run does the steps for ``unstack.sh`` plus additional " "cleaning:" msgstr "" #: ../../source/code-and-documentation/devstack.rst:208 msgid "Removing configuration files for projects from /etc" msgstr "" #: ../../source/code-and-documentation/devstack.rst:209 msgid "Removing log files" msgstr "" #: ../../source/code-and-documentation/devstack.rst:210 msgid "Hypervisor clean-up" msgstr "" #: ../../source/code-and-documentation/devstack.rst:211 msgid "Removal of .pyc files" msgstr "" #: ../../source/code-and-documentation/devstack.rst:212 msgid "Database clean-up" msgstr "" #: ../../source/code-and-documentation/devstack.rst:213 msgid "etc." msgstr "" #: ../../source/code-and-documentation/documentation.rst:3 msgid "Documentation" msgstr "" #: ../../source/code-and-documentation/documentation.rst:5 msgid "" "This section contains information necessary to contributing to OpenStack " "documentation." msgstr "" #: ../../source/code-and-documentation/documentation.rst:9 msgid "Documents in project repositories" msgstr "" #: ../../source/code-and-documentation/documentation.rst:11 msgid "" "All project documentation must follow the same directory structure, which is " "described on the `Project Guide Setup page`_." msgstr "" #: ../../source/code-and-documentation/documentation.rst:14 msgid "The documentation directory structure is the following::" msgstr "" #: ../../source/code-and-documentation/documentation.rst:26 msgid "Installation guide" msgstr "" #: ../../source/code-and-documentation/documentation.rst:28 msgid "" "The installation guide can be found in the ``install`` directory. It " "contains information on anything to do with installing a project from " "packages, for instance, software necessary for installing the project, like " "database installation and configuration, or what parameters should be set in " "the project's config file. If everything is configured properly (described " "below), the project's installation guide is included in the `OpenStack " "Installation Guides`_. The installation guide is not intended to be used for " "production system installations." msgstr "" #: ../../source/code-and-documentation/documentation.rst:38 msgid "Contributor guide" msgstr "" #: ../../source/code-and-documentation/documentation.rst:40 msgid "" "The contributor guide can be found in the ``contributor`` directory. It " "contains project-specific information on contributing to the project and on " "team management. This guide appears only in the project's documentation." msgstr "" #: ../../source/code-and-documentation/documentation.rst:45 msgid "Configuration reference" msgstr "" #: ../../source/code-and-documentation/documentation.rst:47 msgid "" "The ``configuration`` directory contains configuration reference information " "that is either automatically generated (if the project uses ``oslo.config``) " "or manually written (if ``oslo.config`` is not used). For more information, " "see `Sphinx Integration`_." msgstr "" #: ../../source/code-and-documentation/documentation.rst:53 msgid "CLI reference" msgstr "" #: ../../source/code-and-documentation/documentation.rst:55 msgid "" "The ``cli`` directory contains command line tool reference documentation " "which can be automatically generated with cliff’s sphinx integration, or " "manually written when auto-generation is not possible. For more information, " "see `cliff Sphinx Integration`_." msgstr "" #: ../../source/code-and-documentation/documentation.rst:61 msgid "Administrator guide" msgstr "" #: ../../source/code-and-documentation/documentation.rst:63 msgid "" "The admin guide can be found in the ``admin`` directory. It contains " "information on the configuration and operation of the software. The " "project's administrator guide is included in the `OpenStack Administrator " "Guides`_." msgstr "" #: ../../source/code-and-documentation/documentation.rst:68 msgid "User guide" msgstr "" #: ../../source/code-and-documentation/documentation.rst:70 msgid "" "The ``user`` directory contains information targeted at end-users, for " "instance, concept guides, tutorials, step-by-step instructions for using the " "CLI or the project's API, and such." msgstr "" #: ../../source/code-and-documentation/documentation.rst:75 msgid "Reference documents" msgstr "" #: ../../source/code-and-documentation/documentation.rst:77 msgid "" "The ``reference`` directory contains reference information not included in " "the other directories, for instance, automatically generated class " "documentation in library projects." msgstr "" #: ../../source/code-and-documentation/documentation.rst:82 msgid "Publishing documents in project repositories" msgstr "" #: ../../source/code-and-documentation/documentation.rst:84 msgid "" "For the project documents to be linked to on the `OpenStack documentation " "portal`_, the ``www/project-data/latest.yaml`` file in the ``openstack-" "manuals`` repository has to be updated, following the rules of the `template " "generator`_." msgstr "" #: ../../source/code-and-documentation/documentation.rst:89 msgid "Find your project in the file." msgstr "" #: ../../source/code-and-documentation/documentation.rst:91 msgid "Set to 'true' all document options that apply. For example::" msgstr "" #: ../../source/code-and-documentation/documentation.rst:99 msgid "" "If the above structure exists in the project repository and the ``latest." "yaml`` file is updated, the ``publish-openstack-sphinx-docs`` job in the " "``project-config`` repo automatically includes the document in the published " "documentation. For detailed instructions, see the `Project guide setup`_." msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:3 msgid "Using Elastic Recheck" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:5 msgid "This section assumes you have completed :doc:`/common/zuul-status`" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:7 #: ../../source/code-and-documentation/patch-best-practices.rst:12 msgid "Allows you to:" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:9 msgid "" "Enhance the automatic testing the community does on every patch submitted to " "gerrit" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:11 msgid "Report recurring bugs so that you don't need to manually 'recheck'" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:14 msgid "What to do if a test job fails" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:16 msgid "" "When you submit a patch to gerrit and zuul returns the test results for the " "jobs it ran, sometimes one of those tests fails. Most of the time this " "indicates there is an issue with your proposed change and the tests are " "catching it. Sometimes the test run might have tripped over an underlying " "pre-existing bug in OpenStack. Additionally, some times the infrastructure " "for running the tests might have had a failure. To figure this out you'll " "always need to look at the logs from the failed job to understand what's " "happening." msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:24 msgid "" "A comment `recheck` on the patch would trigger the failed job to execute " "again. **DO NOT** just recheck the patch only to see if it fails again. CI " "test resources are very scarce. Read this document to know `how to handle " "test failures `_" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:31 msgid "OpenSearch" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:33 msgid "" "For deeper investigation of related log messages across multiple builds of " "jobs, a community-run `OpenSearch cluster `_ is available, with both a WebUI for " "producing real-time graphs as well as a REST API for more programmatic " "analysis." msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:40 msgid "Past and Future of Elastic Recheck" msgstr "" #: ../../source/code-and-documentation/elastic-recheck.rst:42 msgid "" "At one time, there existed a service to automatically analyze indexed job " "logs in order to match them against curated queries for known bug " "signatures, and leave helpful review comments on changes when those same " "failures were identified in a new build. That service relied on an old suite " "of systems fronted by logstash.openstack.org, which ceased operation in " "April 2022. A recreation of that solution is in progress based on the " "community's new OpenSearch backend, but is not available for general use yet." "" msgstr "" #: ../../source/code-and-documentation/index.rst:3 msgid "Code & Documentation Contributor Guide" msgstr "" #: ../../source/code-and-documentation/index.rst:5 msgid "Code and Documentation Contributors" msgstr "" #: ../../source/code-and-documentation/introduction.rst:3 msgid "Introduction" msgstr "" #: ../../source/code-and-documentation/introduction.rst:5 msgid "" "The heart of open source is the people who are participating in a community " "and it is no different in case of OpenStack either." msgstr "" #: ../../source/code-and-documentation/introduction.rst:8 msgid "" "This chapter will guide you through of all the tools and processes that we " "are using to develop, test, maintain, and document the projects in OpenStack." "" msgstr "" #: ../../source/code-and-documentation/introduction.rst:11 msgid "" "Communication is underrated, but crucial when it comes to participating in " "an open source community. We have several tools that we use for online and " "offline communication, which we encourage you to use." msgstr "" #: ../../source/code-and-documentation/introduction.rst:15 msgid "" "We do not differentiate between the different types of contributions such as " "code or documentation therefore you will find guidance in this chapter for " "all types." msgstr "" #: ../../source/code-and-documentation/introduction.rst:19 msgid "First-timers can refer to the :doc:`quick-start` Guide." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:3 msgid "How to Become a Patch Guru?" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:5 msgid "" "When you are working on implementing a new feature or adding documentation " "to an already existing one it is easy to get carried away by the work itself " "and forget about the unwritten rules of constructing your changes." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:9 msgid "" "This section will guide you through how to create patches that people will " "want to review." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:14 msgid "" "Know how to structure a patch that makes it easier to maintain throughout " "the review process" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:16 msgid "" "Know how to structure a patch that is easier for community members to review" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:19 msgid "The Right Size" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:21 msgid "" "Reviewing large patches is very inconvenient and time consuming therefore we " "always suggest to break down your changes into smaller blocks." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:24 msgid "" "While there is no magic number try to **keep the size of your changes as " "small as possible**, but under a few hundreds of lines changed total. " "Patches that are test heavy with little code change require as much effort " "as code heavy changes." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:29 msgid "" "In rare occasions when there is no good logical breakdown for a change and " "your patch can grow to a thousand lines or more. In some cases it is " "acceptable as you cannot extract the related test changes to another patch " "for instance, but it's not highly recommended." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:34 msgid "" "Always try to extract as much as you can into other patches, like " "documentation or logical parts of the functionality that do not depend on " "common functions in a lower layer." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:38 msgid "" "Longer patches require more time to review; wherever you can, keep the " "length reasonable. And where you can't, you can help the reviewers by adding " "code comments and writing a detailed commit message to describe the changes " "you introduced in your patch." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:44 msgid "Patch Chains, Depends-On Tag and Gerrit Topics" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:46 msgid "" "In the case of complex feature implementation work when you need to " "introduce changes to multiple modules of the same project or multiple " "projects you need to be very careful with managing the dependencies." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:50 msgid "" "There are multiple options to choose from depending on the structure of your " "design. You can either organize the changes in patch chains or you can use " "the 'Depends-On' tag." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:55 msgid "Depends-On Tag" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:57 msgid "" "When you have changes in multiple project repositories you can mark " "dependent patches with the 'Depends-On' tag. The tag will appear as a link " "in the commit message which helps you and also the reviewers to track and " "navigate between the dependencies of your changes." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:62 msgid "" "The 'Depends-On' tag is a marker on your changes and when used a patch " "cannot be merged until all its dependencies are landed." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:65 msgid "" "The tag can be applied to patches proposed for the same repository as well. " "In that case the changes are separate enough to be kept independent which " "means that if you need to fix changes from review comments you can do it on " "a per patch basis. It is also true for rebasing each patch." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:72 msgid "" "In case you use the 'Depends-On' tag you need to download all the changes " "for a feature implementation or documentation change to test the feature or " "build the documentation with all the changes applied. Git will not take care " "of handling the dependencies automatically in this case." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:78 msgid "Patch Chains" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:80 msgid "" "In some cases when you break down the required changes to smaller blocks you " "cannot avoid having direct dependencies between them that prevents you from " "having independent changes. You need to organize your changes in a chain to " "maintain the dependencies which requires some additional care when you work " "with these changes." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:86 msgid "" "Even if you have a chain of patches you still need to keep code changes and " "related tests in one patch as you cannot guarantee that both land in time " "for a release." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:90 msgid "" "When you have a chain Gerrit helps you by listing all the commit titles in " "the 'Related Changes' column on the top right corner of the Gerrit UI. The " "titles are also links which help you navigate between the changes to review " "them when you upload a new version." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:96 msgid "How to Handle Chains?" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:98 msgid "" "A patch chain is easy to handle if you keep in mind a few recommendations:" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:100 msgid "" "Always have a local branch for these changes to ensure that you don't mix it " "together with changes related to another feature or bug fix." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:103 msgid "" "Always handle a chain as one block of changes by rebasing the whole chain " "and keep it up to date when you modify a patch to fix review comments or add " "changes to it." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:107 msgid "" "To modify a patch within a chain you will need to use interactive rebase:" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:113 msgid "" "You need as many '^' as the number of the patch you want to edit first from " "the top of the chain. Alternatively you may wish to use `git-restack `_, which figures out the appropriate " "``git rebase`` command for you." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:118 msgid "" "Gerrit also provides you options to edit the patch itself or only the commit " "message and a few more for more advanced changes, like modifying the author." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:122 msgid "" "To download the full chain you need to download the top patch and Git will " "automatically download all the dependent patches in the chain." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:125 msgid "" "If you only need to modify the top patch in the chain that can be done the " "same way as you update individual patches." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:128 msgid "" "When you upload changes in a chain only the patches that got updated will be " "uploaded. This also means that the review scores on lower patches in the " "chain will be untouched." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:132 msgid "" "Always check the changes you made to each patch and be careful that you " "applied the changes in the right one as patches still get merged " "individually and there is no guarantee that the whole chain gets landed at " "the same time." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:136 msgid "" "For a more in-depth look at managing patch chains, see :doc:`/code-and-" "documentation/patch-series-tutorial`." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:140 msgid "Gerrit Topics" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:142 msgid "" "You have the option to specify a topic for your changes when you upload them " "for review. While Gerrit topics will not add dependency to your patches you " "can apply a search based on the topic that will show you all the relevant " "changes in all the projects where there are patches with the same topic. " "Gerrit will also show them to you in the 'Same Topic' column on the top " "right corner of the page of a review." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:149 msgid "" "This is a good way to help tracking related changes, let that be a feature " "implementation, bugfix or documentation work." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:153 msgid "How to Structure Your Changes?" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:155 msgid "" "When your work item grows above a particular size and you need to upload " "multiple patches it is crucial to structure it well in case of both patch " "chains and independent changes." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:159 msgid "" "It is a good practice to group changes by modules in a project, for instance " "virt driver changes, compute manager and api changes in case of OpenStack " "Compute." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:163 msgid "" "By grouping the changes per module you can also construct the chain or " "dependencies by the hierarchy of the components and always keep the API " "changes last as that will enable the new functionality and that change will " "depend on everything else you needed to touch for your design." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:168 msgid "" "Beyond this you can also look into the functionality to find smaller " "building blocks and make your changes smaller. For instance changes to an " "object can be implemented first that you will use later when you implement " "new API functionality." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:174 msgid "Structural split of Changes" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:176 msgid "" "The cardinal rule for creating good commits is to ensure there is only one " "\"logical change\" per commit. There are many reasons why this is an " "important rule:" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:180 msgid "" "The smaller the amount of code being changed, the quicker and easier it is " "to review and identify potential flaws." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:183 msgid "" "If a change is found to be flawed later, it may be necessary to revert the " "broken commit. This is much easier to do if there are not other unrelated " "code changes entangled with the original commit." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:187 msgid "" "When troubleshooting problems using Git's bisect capability, small well " "defined changes will aid in isolating exactly where the code problem was " "introduced." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:191 msgid "" "When browsing history using ``git annotate`` or ``git blame``, small well " "defined changes also aid in isolating exactly where and why a piece of code " "came from." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:196 msgid "The Right Content" msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:198 msgid "" "Changes that are not related to any feature implementation or bug report can " "be uploaded but are less welcomed by reviewers." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:201 msgid "" "Improvement to either the code or documentation should be part of a larger " "effort, like if you would like to fix typos in documentation then you should " "do it for a larger block, like a whole guide. It is also preferred to report " "a story with tasks for a work item like this that can be tracked later." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:206 msgid "" "It is similar for code improvements. As the community is large and world-" "wide we have coding guidelines, but the style of each individual can still " "be very different. We don't enforce a particular coding style, therefore " "changes related to fix that are less welcomed and are sources of very " "opinionated arguments that should be avoided." msgstr "" #: ../../source/code-and-documentation/patch-best-practices.rst:212 msgid "" "In case of code refactoring work which makes the code more readable and " "easier to maintain by restructuring methods and deleting unused code " "snippets it is highly encouraged to consult with the project team and report " "a story in StoryBoard first and then upload the relevant changes to Gerrit " "for review." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:3 msgid "Tutorial: Developing Changes In A Series" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:5 msgid "" "This tutorial walks through a simple scenario of developing multiple change " "sets in a series on the same branch. If you wish, you can follow along, " "using the `sandbox repository `_, " "executing the commands exactly as they're laid out." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:11 msgid "" "If you are a visual learner, you may prefer `this video `_ " "which does roughly the same thing (but without ``git-restack``)." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:15 msgid "Here we go." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:17 msgid "Start on a freshly-``pull``\\ed master branch:" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:27 msgid "" "When you're working on a blueprint, you want to name your local branch after " "the blueprint. For this example, we'll use ``bp/nova-cyborg-interaction``." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:38 msgid "" "When you ``git commit`` (without ``--amend``), you're creating a new commit " "on top of whatever commit you started at. If you started with a clean, " "freshly ``pull``\\ed master branch, that'll be whatever the most recently " "merged commit in the master branch was. In this example, that's commit " "``3d008a3``." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:43 msgid "So let's say I make an edit for my first patch and commit it:" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:58 msgid "" "I just made commit ``d76195e`` on top of ``3d008a3``. You'll notice my " "branch name (``bp/nova-cyborg-interaction``) came along with me." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:61 msgid "" "Now I'm going to make another change, but just part of it, a work-in-" "progress commit:" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:78 msgid "" "Now commit ``f17f040`` is on top of ``d76195e``, which is still on top of " "``3d008a3`` (aka ``master``). Note that my branch name came with me again." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:81 msgid "" "At this point, I push my series up to gerrit. Note that it makes me confirm " "that I really want to push two commits at once." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:113 msgid "" "Now if you go to either of those links - e.g. https://review.opendev.org/#/c/" "635342/ - you'll see that the patches are stacked up in series on the top " "right." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:117 msgid "" "But oops, I made a mistake in my first commit. My lower constraint can't be " "higher than my minimum in ``requirements.txt``. If I still had my branch " "locally, I could skip this next step, but as a matter of rigor to avoid some " "common pratfalls, I will pull the whole series afresh from gerrit by asking " "``git-review`` to grab the *top* change:" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:129 msgid "" "Now I'm sitting on the top change (which you'll notice happens to be exactly " "the same as before I pushed it - again, meaning I could technically have " "just worked from where I was, but see above):" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:140 msgid "" "But I want to edit ``d76195e``, while leaving ``f17f040`` properly stacked " "on top of it. Here I use a tool called `git-restack `_ (run ``pip install git-restack`` to install it)." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:149 msgid "" "This pops me into an editor showing me all the commits between wherever I am " "and the main branch (now they're in top-first order):" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:158 msgid "I want to fix the first one, so I change ``pick`` to ``edit``:" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:166 msgid "Save and quit the editor, and I see:" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:179 msgid "I fix ``lower-constraints.txt``:" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:185 msgid "...and *amend* the current commit" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:195 msgid "...and tell ``git-restack`` to proceed" msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:202 msgid "" "If I had a taller series, and I had changed ``pick`` to ``edit`` for more " "than one commit, I would now be sitting on the next one I needed to edit. As " "it is, that was the only thing I needed to do, so I'm done and sitting on " "the top of my series again." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:214 msgid "" "Notice that the commit hashes have changed for *both* commits (but not for " "``master``). The top one changed because it got rebased onto the new version " "of the middle one." msgstr "" #: ../../source/code-and-documentation/patch-series-tutorial.rst:218 msgid "" "Now if I push the series back up to gerrit, I get the same confirmation " "prompt, and both changes get a new patch set. If you look at the top patch " "in gerrit, you'll see that patch set 2 shows up as just a rebase." msgstr "" #: ../../source/code-and-documentation/quick-start.rst:3 msgid "Quick Start" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:5 msgid "" "This guide is to list the minimal steps you need to do to push your first " "patch in OpenStack." msgstr "" #: ../../source/code-and-documentation/quick-start.rst:9 msgid "Set up accounts and configure environment" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:11 msgid "To get started, first setup required accounts." msgstr "" #: ../../source/code-and-documentation/quick-start.rst:13 msgid "OpenStack :doc:`../common/accounts`" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:15 msgid ":doc:`../common/git`" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:17 msgid ":doc:`../common/setup-gerrit`" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:20 msgid "Push your change" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:22 msgid "OpenStack uses Gerrit to propose and review the code." msgstr "" #: ../../source/code-and-documentation/quick-start.rst:24 msgid "" "Here is a quick overview of the `Gerrit Workflow `_" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:27 msgid "Push your change and review :doc:`using-gerrit`" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:30 msgid "Practice the workflow using Sandbox Project" msgstr "" #: ../../source/code-and-documentation/quick-start.rst:32 msgid "" "To make sure everything is set up correctly or to understand the workflow " "without trying it on actual projects, you can practice in a Sandbox using " "the :doc:`sandbox-house-rules` Guide." msgstr "" #: ../../source/code-and-documentation/quick-start.rst:36 msgid "" "For further details on contributing to the OpenStack community, please refer " "to :doc:`../index`." msgstr "" #: ../../source/code-and-documentation/references-doc-contrib-guide.rst:3 msgid "OpenStack Documentation Contributor Guide" msgstr "" #: ../../source/code-and-documentation/references-doc-contrib-guide.rst:5 msgid "" "The `OpenStack Documentation Contributor Guide `_ describes how to contribute to OpenStack " "documentation. It contains information on `writing `_, `building `_, and `reviewing `_ documents, as well " "as best practices and `API documentation guidelines `_." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:3 msgid "How to Use the Sandbox Projects" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:5 msgid "" "The tools that we are using in the community can look complicated if you are " "not familiar with them. To help you practice before you use them in action " "we are providing sandbox environments for you where you can practice all the " "steps we describe in this guide." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:10 msgid "This section allows you to:" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:12 msgid "Get an overview of the available projects for practice" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:13 msgid "Get guidelines on how to use them" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:16 msgid "General Information" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:18 msgid "" "All the Sandbox repository and projects are identical to any other active " "project's resources. You can find the same information and same " "functionality as well to ensure you can practice everything you need to know " "about the tool." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:22 msgid "" "You get permissions to perform all the operations in the Sandbox project for " "the sake of practice. When you join a project as a contributor you will have " "limited access to the functionalities as there are actions only core " "reviewers can perform. You can find information about these in the " "respective sections of the Contributor Guide." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:28 msgid "" "The Sandbox repository and projects are maintained by community members with " "occasional cleanup. Please help us with the housekeeping and clean up your " "work, when you are finished with your practice and feel comfortable using " "the tool." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:34 msgid "Sandbox Git Repository" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:36 msgid "" "Git is a version control system that we use to track changes to our source " "code and documentation." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:39 msgid "" "You can find a `sandbox Git repository `_ where you can practice the Git commands before you put together a " "patch to resolve a bug or implement a new functionality." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:44 msgid "You can find instructions on how to use Git in the :ref:`git` section." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:46 msgid "" "You can upload your changes to the sandbox repository and review it on " "Gerrit as it is described in the :ref:`gerrit` section." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:50 msgid "Sandbox Project on StoryBoard" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:52 msgid "" ":ref:`storyboard` is a community-developed task tracking tool. The community-" "wide adoption of the tool is in progress, you will find more and more " "projects who migrated over to using StoryBoard already." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:56 msgid "" "You can find a `Sandbox `_ project in the tool that provides all the functionalities to you as any " "of the other active projects." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:61 msgid "Sandbox Project on Launchpad" msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:63 msgid "" ":ref:`launchpad` is one of the task tracking tools that the community is " "using." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:65 msgid "Launchpad is deprecated and will be superceded by StoryBoard." msgstr "" #: ../../source/code-and-documentation/sandbox-house-rules.rst:67 msgid "" "There is a `Sandbox project `_ " "available there which is created to track bugs and issues related to the " "opendev/sandbox repository." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:5 msgid "Using Gerrit" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:9 msgid "" "This section assumes you have completed :doc:`../common/setup-gerrit` guide." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:11 msgid "Gerrit allows you:" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:13 msgid "Get reviews on your changes proposed to OpenStack repositories" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:14 msgid "Request reviews from specific community members" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:15 msgid "Make quick changes to your patches in the webui" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:18 msgid "Pushing A Change" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:21 msgid "" "This is a quick start version. For a more in depth description of how to " "clone, create a patch and push the change, directions can be `found here " "`_" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:24 msgid "" "Following is a list of the commands that you need to know for your first " "contribution:" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:27 msgid "To clone a copy of some repository::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:32 msgid "" "You can find the same repositories using the search function here: `OpenDev " "git repository browser `_" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:35 msgid "" "After you've completed the Setup and Learn GIT section, the following " "command configures the repository to know about Gerrit and installs the " "``Change-Id`` commit hook. You only need to do this once per repository you " "clone::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:41 msgid "" "To create your development branch (substitute branch_name for a name of your " "choice). It's better to create a new branch for each patch than working from " "master::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:47 msgid "To check the files that have been updated in your branch::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:51 msgid "To check the differences between your branch and the repository::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:55 msgid "" "Assuming you have not added new files, you commit all your changes using::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:59 msgid "" "Read the `Summary of Git commit message structure `_ " "for best practices on writing the commit message. When you are ready to send " "your changes for review use::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:65 msgid "" "If successful, the Git response message will contain a URL you can use to " "track your changes." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:68 msgid "" "If you need to make further changes to the same review, you can commit them " "using::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:73 msgid "" "This will commit the changes under the same set of changes you issued " "earlier. Notice that in order to send your latest version for review, you " "will still need to call::" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:80 msgid "Tracking your Changes" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:82 msgid "" "After proposing changes, you can track them at `Code Review `_. After logging in, you will see a dashboard of \"Outgoing " "reviews\" for changes you have proposed, \"Incoming reviews\" for changes " "you are reviewing, and \"Recently closed\" changes for which you were either " "a reviewer or owner." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:89 msgid "Adding Reviewers" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:90 msgid "" "Sometimes there might be people you need to weigh in on your patch because " "they have a vested interest or are helping mentor you. The easiest way of " "letting them know you have uploaded a new patch or patchset is to add them " "as reviewers in the gerrit web-ui. You can look them up by name, gerrit " "email address, ssh user name, or gerrit id." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:99 msgid "" "In general, its best to avoid over using this gerrit capability because each " "interaction with the patch- new patchsets, comments, CI system votes, etc.- " "will send an email notification to every reviewer on the patch." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:105 msgid "" "If you review a patch you are automatically added to the list of reviewers." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:110 msgid "Gerrit Web Editor" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:111 msgid "" "It is possible to edit your patch in the gerrit web interface and publish " "the change without making the change locally. This is not generally advised " "for larger code updates since it doesn't automatically update your local " "working branch. In some cases, where the patch is basically ready to merge " "aside from a small pep8 failure- whitespace at the end of line, needing to " "wrap a line, etc- this gerrit feature can be convenient to make a quick edit " "and publish the change without having to go through the entire 'git add', " "'git commit --amend', 'git review' process." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:121 msgid "" "To access the Gerrit Web Editor click on the icon that looks like a pencil " "writing on paper next to the patch set number at the top of a Gerrit Code " "Review page for a file." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:130 msgid "Reviewing Changes" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:132 msgid "" "Reviewing changes is often suggested as a way to get started on a project. " "Whether this is how you choose to get started or not, it's an important " "community activity. See `How to Review Changes the OpenStack Way `_ for " "more detailed guidance on when to use which votes on a change review." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:140 msgid "**Inline Comments**" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:142 msgid "" "If you have questions about the way something is phrased or done, or have " "found some other issue the easiest way to let the author of the patch know " "is to comment on that place inline. The inline comments are posted " "collectively when you hit the 'Reply' button and add your vote on the " "patchset." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:149 msgid "" "Until you click 'Reply' and vote on the patch, any inline comments you've " "made exist as drafts." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:152 msgid "**+/- 1 & 0**" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:154 msgid "" "The basic set of values contributors have to vote with on a patch is: -1, 0, " "or +1. These values correspond to a relatively simple system." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:160 msgid "" "`-1`_: This patch needs further work before it can be merged. A -1 is " "usually given when the reviewer sees some issue that needs to be fixed " "before the patch can be merged. The issues the author needs to address " "would, ideally, have inline comments posted on them unless there is some " "larger issue. If there is something wrong with the overall approach, you are " "able to leave an overall comment with the vote to raise your concerns." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:169 msgid "" "If your patch gets a -1 it is not bad news, it just means you need to do a " "little more work." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:172 msgid "" "`0`_: No score. This is the default score when replying to a patchset. " "Generally it's kept as the vote when someone has a question about the " "patchset or doesn't have a fully formed opinion of the patchset yet - it " "requires more time, testing, or investigation." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:178 msgid "" "`+1`_: Looks good to me, but someone else must approve. This does not mean " "that there is nothing to comment on, just that there aren't any issues that " "would block the merging of the patch. You can still make comments on " "nitpicky things the patch owner can address if others find issues with the " "patch. These comments might also be something to address in a followup patch " "as opposed to another patchset." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:187 msgid "**+/- 2 & +W**" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:189 msgid "" "Core reviewers have additional voting choices aside from the basic set. Like " "the basic set, the numbers map to a simple system of meaning:" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:195 msgid "" "`-2`_: Do not merge. This score does not often appear and when it does, it's " "for a good reason:" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:198 msgid "" "Most often, some deadline has passed and since no more changes are being " "accepted till the new release development begins, the patch is `being held " "`_." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:201 msgid "" "There is an issue with the approach taken in the patch and it needs to be " "discussed with a larger group, likely in a meeting." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:203 msgid "" "The patch submitted is a duplicate or at odds with another patch submitted." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:207 msgid "" "Only the person that voted the -2 can remove the vote and it will persist on " "all new patchsets." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:210 msgid "" "`+2`_: Looks good to me (core reviewer). Depending on the project team and " "repository, merging a patch will require at least one +2 vote if not two +2 " "votes." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:214 msgid "" "+W: Approved. This patch will now be run through a final round of checks " "before it is merged into the repository." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:218 msgid "**Reviewing Best Practices**" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:220 msgid "" "If you can, test the code! In some cases you may not have access to the " "specific hardware needed, but in general you should be able to test the " "changes or look at the zuul build of the documentation so that you are doing " "more than just looking at the code or documentation change." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:226 msgid "Checking Out Others' Changes" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:228 msgid "" "It is possible to check out other contributors' patches from Gerrit and even " "`make changes to them `_; however, you should always " "discuss any changes with the contributor before you start working on their " "patch." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:238 msgid "The change ID can be found on the web UI of Gerrit:" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:243 msgid "" "After checking out the patch, you will be switched to a new branch " "automatically, on which you can make your changes." msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:247 msgid "Cherry-picking" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:249 msgid "" "If your commit depends on a change which has been updated since you started " "your work, and you need to get the latest patchset from that change, you can " "cherry-pick your own changes on top of it:" msgstr "" #: ../../source/code-and-documentation/using-gerrit.rst:257 msgid "The change ID is the same as in the previous case." msgstr ""