Skip to content

Home

Jump to bottom
Matyas Selmeci edited this page Jan 28, 2025 · 4 revisions

xrootd (PelicanPlatform patchset)

This repo is for organizing patches that get applied to OSG builds of XRootD RPMs. (It is not meant to be a fork of XRootD.) This gives us a workflow for managing patch updates and ordering.

Workflow for developers (Pelican team)

New XRootD release

  1. Create a branch based on the new tag, named after the tag with "-pelican" appended. For example, the branch for patches applied to "v5.7.3" should be "v5.7.3-pelican".

  2. Cherry-pick all the patches that were applied to the previous branch. If Git reports that the cherry-pick is empty (meaning the patch is already applied), resolve the corresponding issue.

  3. Change the default branch of the repo to the newly created branch.

Adding a new patch

  1. Create a GitHub issue for the patch; include a link to the upstream PR (if available) for the patch. Apply the "osg-not-built" label to the new issue.

  2. Squash the patch into a single commit; apply it to the branch we want to apply the patch to. Tip: If you add ".diff" to the end of a PR URL, you will get a squashed diff of the PR. (It won't have a commit message though.)

Prefix the subject of the patch (i.e., the first line of the commit message), with the corresponding issue, so it's easy to link the two. For example, if the issue is "Fix MacOS poller" and it's issue #11, for the subject, use "11-Fix MacOS poller".

Do a direct push, don't make a PR.

Assuming the new patch is HEAD, run git show HEAD | git patch-id --stable and add a comment in the GitHub issue with the output.

  1. Let the OSG Software Team know about the new patch.

Updating an existing patch

  1. Get a new squashed diff for the patch, as a file. (For example, 1234.diff.)

  2. Check out the branch you want to apply the patch to. (For example, v5.7.3-pelican.)

  3. Make a backup branch. (For example, v5.7.3-pelican.bak). Push it.

  4. Take a deep breath, do an interactive rebase on the tag the branch is based on (For example, git rebase -i v5.7.3).

  5. Find the commit you want to change in the list and change "pick" to "edit". Save.

When the rebase gets to that commit:

  1. git checkout HEAD~ -- . will undo the file changes from that commit in the working tree, but leave the current commit alone. (This will let you reuse the commit message.)

  2. git apply 1234.diff to add the changes from the new patch to the working tree.

  3. git commit --amend -a to change the current commit to have the new changes instead.

  4. Run git show HEAD | git patch-id --stable and add that as a comment to the GitHub issue. Tip: Put it in a text editor first in case you need to make multiple attempts at the interactive rebase.

  5. git rebase --continue to keep going with the rest of the commits.

If there are any merge conflicts

  1. Fix the conflicts using git mergetool

  2. Do git commit --amend -a

  3. Run git show HEAD | git patch-id --stable and add that as a comment to the GitHub issue for the commit you just fixed. (Hopefully it has the issue number in the subject!)

If you mess up, do git rebase --abort and try again. If your repo is still in a bad state, follow that up with git reset --hard v5.7.3-pelican.bak.

  1. If you're good with the results, do a force push.

  2. Update the issue for the patch to remove the "osg-built" label (if present) and add the "osg-not-built" label.

  3. Let the OSG Software Team know about the updates.

Workflow for packages (OSG SW team)

If the version to apply the patches to is, for example, v5.7.3:

  1. git clone -o upstream https://github.com/xrootd/xrootd && cd xrootd
  2. git remote add -f pelican https://github.com/PelicanPlatform/xrootd
  3. git format-patch v5.7.3..pelican/v5.7.3-pelican

Add the short git patch-id to the filename:

for it in *.patch; do
	it_base=${it%.patch}
	hash=$(< "$it" git patch-id --stable | cut -b -7)
	[[ $hash ]] && mv "$it" "${it_base}~${hash}.patch"
done

(The hash created by git patch-id is based on the contents of the patch, not the commit as a whole (so it excludes the commit message from the hash calculation for example). If a rebase had no effect on a patch, its patch-id will be the same.)

  1. Move all the created patch files to the xrootd/osg/ dir in the OSG SW branch you're building for (e.g. 24-main)

  2. If any are new, svn add them and also add them as PatchN files.

  3. Remove old ones with svn rm.

  4. Go to the %prep section and adjust the %autopatch lines if necessary.

  5. Bump the release, add a changelog entry, do a scratch build.

  6. Commit, do a real build.

  7. If you're good with the results, go to the issue for each patch, remove "osg-not-built" (if present) and add "osg-built".

Clone this wiki locally