Re: Issues in the Patch Tagging Guidelines
On Wed, 16 Aug 2023 at 12:25:13 +0200, Guillem Jover wrote:
> Here's what a git format-patch patch looks like:
>
> ,---
> From 9767e87d08803d78208464be3652a9231b6b08e3 Mon Sep 17 00:00:00 2001
> From: Guillem Jover <guillem@hadrons.org>
> Date: Thu, 10 Aug 2023 20:31:02 +0200
One particularly popular tool for managing debian/patches is gbp pq, which
removes the leading "From " line, and the trailing "-- " and git version,
in an effort to normalize the patch content in a way that will reduce
spurious changes when the patch series is rebased.
I think ideally the Patch Tagging Guidelines should *allow* the first line
to start with "From ", with no semantic meaning, so that maintainers of
simple packages can drop `git format-patch` output directly into
debian/patches; but should not *require* that first line, so that the
current output of `gbp pq export` is considered to be equally correct.
I personally think the extent to which git has "won", both upstream and in
Debian package maintenance, means that the Patch Tagging Guidelines should
be encouraging the git-like style as primary, with From/Date/Subject
in a header and all Debian-specific fields in a trailing pseudo-header,
the same layout that's familiar for Signed-off-by and similar tags used
by many upstream developers:
From <anything here, optional, ignored>
From: ...
Date: ...
Subject: <short description>
<long description>
<more long description>
Signed-off-by: ...
Bug: https://...
Origin: vendor, Debian
Forwarded: https://...
---
<the actual diff>
That would encourage interoperability with how patches are represented and
tagged (formally or informally) in many non-Debian environments.
When interacting with developers of non-Debian-based distributions (for
example one of my $work projects is Arch-based), I'd like to be able to
point to DEP-3 and say "consider using this format" with a minimum of what
developers of the other project would consider to be weird Debianisms:
concepts like tracking whether a patch is upstreamable in principle,
and how far it has got in actually going upstream, are equally useful
for any downstream distribution. Emphasizing the familiar git-like format
in preference to deb822 would be a step in that direction.
smcv
Reply to: