Make it easier to access upstream source diffs from dist-git PR’s

musicinmybrain commented 3 months ago

Description

As a Fedora packager, I always need to know what I am packaging. For each update, I skim the source diff, looking for things like:

New licenses, so I can verify they are allowed and document them in the spec file
New bundled dependencies that need to be unbundled or justified and documented
Things like bundled fonts, precompiled/preminified CSS or JavaScript, etc. that packaging guidelines prohibit me from packaging in the binary RPMs, even if I can distribute them in the source RPMs
New documentation files or other things that need to be explicitly added to the binary RPMs
Metadata or build-system changes, such as changes to the upstream description text or new Python extras

There are four steps in obtaining a source diff in a browser for a project with an upstream on GitHub. I’ll use https://src.fedoraproject.org/rpms/snakemake/pull-request/42 as an example.

Find the upstream project URL, e.g. https://github.com/snakemake/snakemake.
Find the tag for the current release, e.g. https://github.com/snakemake/snakemake/releases/tag/v8.5.4
Figure out which release is packaged. Even if I’m keeping up with upstream, sometimes several releases come out in quick succession, so it’s not always the previous one. I usually navigate to the dist-git project page, e.g. https://src.fedoraproject.org/rpms/snakemake
Use the compare dropdown from the tag on GitHub to obtain a source diff, e.g. https://github.com/snakemake/snakemake/compare/v8.5.3...v8.5.4

Especially for projects with upstreams on GitHub, the addition of the “Upstream tag” link in a Packit PR has already helped a lot with this: it takes care of steps 1 and 2.

@majamassarini asked me to file this issue based on our email discussion.

Benefit

Since Fedora packagers are responsible for checking what they package, this should be beneficial for almost all Fedora packagers who use Packit pull-from-upstream jobs.

Importance

At this point, this is a very low-priority improvement for me. Checking a new upstream release will always involve some manual effort, and the addition of the “Upstream tag” link has already greatly reduced the time it takes to get to a source diff.

What is the impacted category (job)?

General

Workaround

[X] There is an existing workaround that can be used until this feature is implemented.

Participation

[ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)

lachmanfrantisek commented 3 months ago

Hello @musicinmybrain !

Thanks for writing down your usecase!

This is a nice input for https://github.com/packit/packit-service/issues/2299

I am still not sure if we should put these things into the PR description or have it as a PR status (together with some other relevant checks). But putting it into the description is in the current state much easier to do. (We just need to think about non-GitHub usecases.)

lachmanfrantisek commented 3 months ago

Just one question:

Figure out which release is packaged. Even if I’m keeping up with upstream, sometimes several releases come out in quick succession, so it’s not always the previous one. I usually navigate to the dist-git project page, e.g. https://src.fedoraproject.org/rpms/snakemake

What specifically are you interested in? Released/build version or a last version in the specfile? (The specfile version bump is visible in diff so it's probably not that one.) I am thinking how to show this info. (It's nice that on the main page, the table is updated unlike anything we put into the PR.)

musicinmybrain commented 3 months ago

What specifically are you interested in? Released/build version or a last version in the specfile? (The specfile version bump is visible in diff so it's probably not that one.) I am thinking how to show this info. (It's nice that on the main page, the table is updated unlike anything we put into the PR.)

For packages I maintain, the version in the spec file should be the same as the latest built version. There’s normally no good reason to push something to dist-git and not build it. So you’re right that checking the spec/dist-git diff is another quick way to find the previous version number. Mostly, I’m interested in making sure that nothing changes in the Fedora package without a human reviewing it first, and whatever’s in dist-git should have already been reviewed before merging it.

musicinmybrain commented 3 months ago

https://github.com/packit/packit/issues/2195 is another approach to the same problem. I don’t care if I look at the source diff via a URL on the upstream forge or via some kind of generic downstream source diffing functionality. For packages that aren’t hosted on a forge with nice in-browser diffs, I extract the old and new sources and look at the diff in the terminal.

packit / packit-service