Skip to content

Contributing

Jump to bottom
Julio González Gil edited this page Nov 24, 2020 · 30 revisions

Code and documentation

To know what piece of software is where, you can check https://www.uyuni-project.org/pages/source-code.html

Git

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

  1. 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.

  2. Create an new branch from master.

  3. Develop the feature or the bugfix on that branch: code, tests and changelogs (last two 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 need to add a changelog to be used for the RPM/Deb packages.

  4. Create a Pull Request. The base branch will always be master.

    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)

  5. 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.

  6. 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.

Open Build Service (OBS)

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

Some examples are the patterns or the product definitions.

To update such packages we use OBS branches.

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

Git changelogs

The best person to write a changelog is the person who fixed the bug or implemented the feature.

Every change must contain changelog entries, with some exceptions depending on the repository.

uyuni-project/uyuni repository

Exceptions:

  • You are fixing a test.
  • You are changing something that doesn't affect a package.

Procedure:

  1. Check what packages your PR is changing. The easiest way is checking the folder rel-eng/packages. Each file there represent a package and contains the path used to build the package. Inside that path you will find a <packagename>.changes file.
  2. For each package, open its .changes file.
  3. Add your new entry on top. For example - Fix taskomatic to avoid crashes when using Java 3000. Do not add a header with the date, your name and your email.
  4. If the first line on the changes file is a separator (-------------------------------------------------------------------) make sure there's an empty line between the separator and your new entry.
  5. Make sure you commit the changes to the changelogs.

Other repositories

Check their contributing guides for details.

Add one or more lines on top of the *.changes file without the date/email header. make the change of the changes file an extra commit. This will make it easier to cherry-pick or merge in other branches.

Help others

You can help other people on the mailing lists, Gitter or by testing and reporting bugs.

Check the Contact Page for the details

Translations

Check the Translations section.

Clone this wiki locally