Skip to content

Contributing

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

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 will need to add a changelog to be used at the RPM/Deb packages.

  4. 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)

  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 at git repositories, but directly at 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 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).

Changelogs

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

Every change (PR or direct change) should contain also changes to all the affected changelogs, with some depending on the repository.

uyuni-project/uyuni

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.

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

Clone this wiki locally