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

If you want to add support for a new OS or a new OS version, please have a look at the following places:

• sumaform
  • add client support for libvirt (base/maint.f, host/user_data.yaml)
  • add new image to image list (null/base/variables.tf, cucumber_testsuite/variables.tf)
  • add new client to controller (salt/controller/bashrc, controller/variables.tf, controller/main.tf)
• test suite
  • add new nodes to twopence_init.rb, constants.rb, env.rb
  • add/refactor tests
  • create new features inside init_clients to bootstrap as minion/SSH minion (build validation)
  • add product synchronization (add the client to the relevant features inside the reposync folder)
  • update YAML file(s) inside run_sets

Forks are good because:

• You work in an isolated repository where you can mess things without affecting others.
• GitHub actions running in your fork don't count to the limit for the Uyuni project, meaning we can run more actions in parallel.
• You can still collaborate in forks:
  • People can send suggestions via the PR UI and you can accept them,
  • Or to allow direct contributions, you can still add collaborators to your fork

Check the GitHub documentation for more information.

Signing commits with a GPG/SSH key is mandatory for contributing. That way your commits will be marked as verified on GitHub so other people can be confident that the changes come from a trusted source.

If you are not doing it already, check out the GitHub documentation.

Since it's mandatory to have signed commits in the Uyuni repository, "Rebase and Merge" option is not available in the GUI. This is because GUI rebase operations rewrite the commit history, and lack the mechanism to re-sign commits during the process.

However, rebasing PRs before merging is still a good practice to maintain a clean and readable Git history. This section shows you how to manually rebase and merge your PRs using the git CLI, ensuring your commits remain signed.

Let's assume you have an open PR with your work on a feature branch (the head branch) that you want to merge into master (the target branch).

1. Update your local target branch: First, ensure your local master branch is up-to-date with the remote repository.

   $ git checkout master
   $ git pull

2. Switch to your feature branch: Now, move to the branch containing your changes.

   $ git checkout feature

3. Rebase your feature branch onto master: This step rewrites your feature branch's history, so it appears as if you started your work from the latest master.

   $ git rebase master

   • Conflict Resolution: If conflicts arise during the rebase, Git will pause and prompt you to resolve them. After resolving, use git add <conflicted-files> and then git rebase --continue. To abort the rebase at any point, use git rebase --abort.
   • Signing Commits: Ensure your Git configuration (git config --global commit.gpgsign true) is set up, or consider using git rebase --signoff master if appropriate for your workflow. The rebase process will preserve existing signatures unless the commit content is changed during conflict resolution.

4. Synchronize PR with feature branch: Your local feature branch is now different from the state of your PR. The changes need to be pushed to Github. Since the branch history was rewritten, the pushing the changes requires the --force-with-lease flag. This flag ensures you are not missing any updates to the PR (e.g. by other collaborators).

   $ git push --force-with-lease

5. Wait for CI tests: GitHub will detect the rebase and automatically re-run CI tests on your PR. It's crucial to wait for at least the mandatory tests to pass before proceeding.

6. Merge your feature branch to master: Once the tests pass and the PR is ready, switch back to master and perform the merge.

   $ git checkout master
   $ git merge --no-ff feature

   • Using --no-ff: The --no-ff (no fast-forward) option is recommended as it forces Git to create a new merge commit, even if a fast-forward merge were possible. This explicitly records the merge event in the history, preserving the logical grouping of your feature branch's commits and contributing to a clearer, more traceable history.

7. Review and push: Finally, review the history and push your changes to the remote repository.

   $ git log --oneline -20 # Optional: review recent commits
   $ git push

   Note: For this push to successfully merge your PR on GitHub, the feature branch must correspond to an open PR that is ready to be merged.

If you change something relevant for the user, a changelog entry must be added to all affected packages. How to do that depends on where the packages are being developed (details below)

All changelog entries must follow https://en.opensuse.org/openSUSE:Creating_a_changes_file_(RPM).

In particular:

• You shall not modify any existing component (where component is a text enclosed between ----------).
• Small typo fixes are accepted, as is the addition of bug references, and trimming useless trailing whitespace.
• Limit your maximum line length to 67 characters.
• All entries must start with a dash (-). You can add second-level using asterisks (*). Third-level or deeper bullet points are not defined, but in any case do NOT use asterisks for it.
• If you add product names, use the right capitalization and format.
• Use the right indentation for each line.
• If you bump the package version because of changes from upstream, make sure the list of changes is on a second-level list
• If you add/remove/change a patchfile, you need to mention it

Very important: the changelogs must be understandable for users, and relevant for them.

Some examples of wrong changelog entries:

- Fixed a crash

What crash?

- Port PR #1165 from upstream

What's that PR about?

- Enable OpenSuSE 15.3 as a supported client

Name is openSUSE Leap

- cobbler20-setup was removed

Why?

- Enable support for the following products:
  + openSUSE Leap 15.3
  + SLE Micro 5.2

Use * instead of + for the second level list.

- Enable support for the following products:
* openSUSE Leap 15.3
* SLE Micro 5.2

Wrong indentation

- Update to grafana 5.1.6
- Refresh branding
- Change authentication method to use LDAP by default

Changes for 5.1.6 should be on a second level list.

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

In general there should always be changelogs for all PRs, with some exceptions:

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

Procedure:

Make sure you read the rules for changelog

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 current version of the package, and the path for the package. Inside that path you will find a <packagename>.changes file. If your PR affects any of the paths or children of such paths, you need a changelog entry.
2. You must not modify the .changes file directly. For each package, create a file named as <packagename>.changes.<author>.<feature> in the same directory as the .changes file and write your entries in it. For example - Fix taskomatic to avoid crashes when using salt 3000. Do not add a header with the date, your name and your email.
3. Make sure you commit the new changelog files. During release, these files are compiled into the master changelog (.changes) files.

Alternatively, you can use the helper script in mkchlog script from uyuni-releng-tools package to automate the file creation. If run without an argument, it creates a changes file with proper naming and opens a text editor for you to add your entries. Run mkchlog --help for usage information. You can run the tool from any subdirectory of any package.

A GitHub action called "Changelogs" will test any open PR for changelogs. If you don't want to add changelog entries for one of the reasons mentioned above, you can check the "No changelog needed" checkbox in the PR description template to skip this test. If this is the case, please explain the reason in the description for reviewers' approval.

Check their contributing guides for details.

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 changelog entries. Remember the guidelines above, in particular remember to mention patches
5. Commit your changes to your branched package (osc ci -m "<message>")
6. Create a SR (osc sr or do it from the web interface).

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

Check the Contact Page for the details

Check the Translations section.