Contributing

Git

We work with Pull Requests, so you need to be familiar with them and with the concept of forking.

If this is your first contribution: fork the git repository you want to change, and then clone it to your computer.

If this is not your first contribution: Go to your local clone and make sure your master branch is synced against upstream.
Create an new branch from master.
Develop the feature or the bugfix on that branch: code and tests (where applicable).

You can freely commit and push. Pushes will go to your forked repository at this stage.

Amend commits or squash them together when it makes sense.

IMPORTANT: In most cases, specially if you plan to submit to the uyuni-project/uyuni, you will need to add a changelog to be used at the RPM/Deb packages.
Create a Pull Request. For the uyuni-project/uyuni repository you will need to fill a template explaining the changes.

Use the checkboxes and pay attention to the data requested (for example screenshots if it makes sense)
If you are developing a new feature (or changing an existing one) that is covered by the documentation, you need to prepare Pull Request for this.

Reference the Pull Requests for the documentation at the Pull Request for the code.
A reviewer should self-assign soon and will either merge the Pull Request or request clarifications or changes.

NOTE: We plan to add automation to assign reviewers automatically.

There are some packages that we do not maintain at git repositories, but directly at OBS.

Some examples are the patterns or the product definitions.

To update such packages we use OBS branches.

Branch the package
Checkout the package to your computer.
Change the package as needed (update sources, update patches, or update the SPEC, as applies)
Use osc vc to add a new changelog entry. It has to be something useful for users.
Commit your changes to your branched package (`osc ci -m "")
Create a SR (osc sr or do it from the web interface).