Branching within rpm git repos

I’ve been thinking about what branch management would look like if we separated branches that track upstream releases from branches that feed Fedora releases.

Goals:

  1. Separating branches that track upstream release series from the branches that feed Fedora releases enables dist-git workflows that have more in common with source-git workflows. This may put us on the track to tooling that supports both equally well.
  2. Fedora generally builds only one release for any upstream major release series during a Fedora release. Users might require a release from either an older minor release series or a newer minor release series than the one shipping in Fedora. Continuous tracking of upstream release series provides a foundation for local tooling to build Software Collections, containers, etc.
  3. The maintainer community may be more open to full automation of branches that track upstream release series, if they are distinct from the branches that feed Fedora releases. Automatically maintained branches reduce friction for tracking upstream releases.
  4. Documenting this workflow is an opportunity to discourage maintainers from rebasing a package during a release, and discuss the conditions under which it can be permitted.
  5. We may have opportunities to introduce new branches to support new types of builds. In particular, we might look at “distroless” container builds, software collections, or nightly builds.
  6. I’d like to look for a way to either integrate “compat” packages into the same git repo, or to pre-populate “compat” git repos based on an existing branch (though the latter doesn’t require the changes discussed here.)

There are several types of events in upstream projects that I think we should track and automatically represent in dist-git repos:

  1. New release in an existing release series
  2. New release series
  3. Release series reaches EOL

… and events in Fedora releases that automation should handle (or does handle, today):

  1. New Fedora release branches
  2. Compat package is requested

In a hypothetical dist-git repo, the initial state: only the upstream release 1.0 series exists. Rawhide(main) and f42 branches exist, along with a release-1.0 branch, but they are currently at the same commit, which details 1.0.0

---1.0.0   main release-1.0 f42

Event 1: Upstream publishes a new release in an existing release series, version 1.0.1. Automation adds a commit to the release series branch (release-1.0) and ff-merges main because it is at the same commit, but not Fedora release branches. It is the maintainer's responsibility to merge the change into the f42 release branch in order to promote the change into a release.

---1.0.0---1.0.1 main release-1.0
  \1.0.0         f42

The maintainer merges those changes, bringing the branches back together.

---1.0.0---1.0.1 main release-1.0 f42

Event 2: Upstream publishes a new release series, 1.1. Automation pushes a new change onto the main branch, (which does not affect the release-1.0 or f42 branches) and creates a new branch for the new release series.

---1.0.0---1.0.1---1.1.0 main release-1.1
          \1.0.1         release-1.0 f42

Upstream also publishes version 1.0.2. Fedora automation adds this to the release-1.0 branch, which diverges from f42 as a result.

---1.0.0---1.0.1---1.1.0 main release-1.1
          \1.0.1---1.0.2 release-1.0
          \1.0.1         f42

The maintainer reacts by merging the new release into f42.

---1.0.0---1.0.1---1.1.0 main release-1.1
          \1.0.1---1.0.2 release-1.0 f42

Event 3: Upstream ends maintenance of the release-1.0 series. The maintainer is notified that the series has reached EOL, and reacts by merging changes from release-1.1 into the F42 branch.

---1.0.0---1.0.1---1.1.0           main release-1.1
          \1.0.1---1.0.2  \        release-1.0
          \1.0.1---1.0.2---\-1.1.0 f42

Fedora event 1: Fedora branches a new release from main.

---1.0.0---1.0.1---1.1.0           main release-1.1 f43
          \1.0.1---1.0.2  \        release-1.0
          \1.0.1---1.0.2---\-1.1.0 f42

Local build tooling might take a build definition like the following, where “build” describes a list of git repositories to clone and a branch to check out. Each of those are rebuilt with “mock –rebuild –chain”. Finally, “install” specifies a set of packages to install, which would select first from the results of the build, and then from the base platform’s package set. These could be built for and installed in something like Software Collections or a container image.

If the package git repositories provide branches that track upstream release branches, maintained by automation, this sort of tooling can provide users a straightforward way to build specific release series on demand.

---
  base: f42
  source:
    type: fedora
    url: https://src.fedoraproject.org/rpms/
    build:
      - openblas:rawhide
      - rocm:rawhide
      - rocm-compilersupport:rawhide
      - python-torch:rawhide
    install:
      - openblas
      - rocm
      - rocm-libc++
      - rocm-lld
      - rocm-clang
      - python3-torch