openwrt / openwrt/packages

CI should not plainly fail hard on patches not being byte-identical to what `/refresh` produces

Open
#30,494 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Makefile
Stars
4.6k
Forks
4k
Avg merge
3d 12h
Merged PRs (30d)
134

Description

I get the idea of having patches in a unified and formally correct format. I also get that patches should apply cleanly.
However forcing them being byte-identical to what /refresh produces has side effects, such as not being able to carry over patches verbatim and unchanged from other sources, e.g. from proposed PRs or maintained in other projects. It essentially forces us to fork respective patches.

By that I don't even mean changes to the format (git format-patch output always differs from quilt output) - which are already annoying by themselves - but I can somehow deal with.

But it's the loss of actual information created by a refresh.
A file holding several patches is merged into one. Mailbox-style files, as produced by git format-patch for a series patch set apply fine, but refresh keeps only the first header. The authorship, dates, subjects and descriptions of every following patch are dropped.
This is especially nonsense when the very same patchset is already proposed as PR upstream, resulting us having to diverge from that in order to make the CI happy, actively working against the goal of keeping downstream patches upstream'able.

Also, after a refresh the file no longer says which upstream commit or version it came from unless the description says so as the description is the only part quilt leaves alone.

The CI complaining about it and encouraging and maybe even pushing for the desired outcome I'm fine with - especially within PRs.
But for good(TM) reasons overriding them should at least not cause the buildbots to fail. That's just too much.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the CI check that compares patches with /refresh output and read the submission guidance in CONTRIBUTING.md. Determine how the check handles justified differences, then make the desired behavior explicit: report or encourage non-identical patches without making the build fail. Done means valid patches can preserve upstream metadata and still pass CI.

Written by the indexing model from the issue text.

Assessment

Domain
build-system, ci-cd
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.