Skip to content

Salt Maintenance Workflow: Update changelog and backport tracking #104

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master-new-maintaining-workflow-for-salt
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 8 additions & 30 deletions accepted/0000-salt-new-maintaining-workflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,7 @@ pkg/suse/html.tar.bz2
pkg/suse/salt-tmpfiles.d
pkg/suse/transactional_update.conf
pkg/suse/update-documentation.sh
pkg/suse/mkchlog.sh
pkg/suse/rpmchangelogs
pkg/suse/_multibuild
pkg/suse/salt.spec
pkg/suse/changelogs/factory/salt.changes
Expand All @@ -77,41 +77,19 @@ This is the place now where all those files will be maintained.

#### Tracking upstream and downstream patches

This RFC proposes the usage of "obs_scm" service as the mechanism to pull the sources for the Salt package to build. This service will automatically produce a sources tarball according to a configured GitHub branch.
This RFC proposes the usage of "obs_scm" service as the mechanism to pull the sources for the Salt package to build. This service generates a sources tarball based on the content of a configured GitHub repository.

For the regular Salt maintenance, this means it won't be needed anymore to manually produce patch files to add them to the spec file, as the tarball now contains the updated sources (with the exception of EMBARGOED bugs, where patches are still needed as we cannot push any fix to public GitHub repositories).
Except for bugs under embargo, we won't use patches in the spec file. The generated tarball includes the latest changes we merged into our `openSUSE/release/<current release>` branch.
Bugs under embargo use a different workflow with manually created patches since we cannot push fixes for such bugs to our public Github repository.

To avoid losing the useful labeling of "PATCH-FIX_UPSTREAM" and "PATCH-FIX_OPENSUSE" (with a direct link to the origin PR on the spec file for each new patch we introduced into our Salt package), we will keep adding this information to the spec file on every new PR but this time without adding the patch itself, only the comment.
We will therefore not track bug fixes in the spec file anymore. The origin of a bug fix, i.e. whether it is backport from upstream or not, will be stored in a Git note attached to the commit of each bug fix. Git notes can be added after bug fixes are merged without modifying the Git history.

#### Salt RPM changelogs

As mentioned, the changelog files are now maintained in the `openSUSE/salt` GitHub repo, under `pkg/suse/changelogs/` directory.
As mentioned, the changelog files are now maintained in the `openSUSE/salt` GitHub repo, under `pkg/suse/changelogs/` directory. New changelog are part of pull requests to `openSUSE/salt`.
Our packaging artifacts will contain a `rpmchangelogs` Python script to easily `add`, `modify` and `remove` changelog entries for all changelogs at once.

Our packaging artifacts will contain a `mkchlog.sh`, which is a helper script to generate a changelog entry to all maintained changelog in one shot. Something like this:

```bash
echo "Generating changelog entry for Salt package"
if ! osc vc _temp.changes;
then
exit 1;
fi

echo "Update changelog files"
echo >> _temp.changes

for i in $(ls changelogs/*/salt.changes); do
echo "$(cat _temp.changes $i)" > $i
git add $i
done

rm _temp.changes
```

When creating a PR to `openSUSE/salt` the user must also include the corresponding changelog entry for all maintained changelog files.

Similarly to the main Uyuni repository, we should add a GitHub action to warn the user in case no changelog entry is added in the PR.

NOTE: I think it is better to decouple commit messages (focus on developers) from changelog entries (focus on users/customers), so I prefer to not use commit messages from "openSUSE/salt" to autogenerate the changelog entries but rather to manually write a meaningful changelog message to be included in your PR as part of your changes. Similarly to what we do in other Uyuni repositories.
We will use a Github status check to prevent us from merging pull requests without changelogs, like we already do in `uyuni-project/uyuni`

### OBS project structure

Expand Down