Refresh of the Patch Tagging Guidelines
Hello,
it's been quite some time that people have been arguing for a refresh of
DEP-3 Patch Tagging Guidelines. Two years ago I replied that I did not
have time to allocate for this, but I finally found some time and
motivation.
So if you are interested, please head over to
https://salsa.debian.org/dep-team/deps/-/merge_requests/25 to review and
comment.
The biggest changes is that we now clearly recommend the "Git-compatible"
format over the traditional "Deb822" format and they are now documented
separately for better distinction. This was argued for by Simon McVittie
at multiple occasions and I agree that it makes sense given how widespread
Git is nowadays.
We also have some pseudo-code that parsers should follow to determine the
official status of the patch if they want to highlight when patches must
be forwarded upstream. This was requested by Lucas Nussbaum as part of his
work on UDD.
Here are some replies to Guillem's comments from
https://lists.debian.org/debian-devel/2023/08/msg00067.html:
> * dpatch complicates parsing, it is deprecated, probably worth dropping
> support for it.
That part is gone.
> * Although the guidelines seem to intend for git formatted patches to be
> supported, the actual specification of the format is not very clear
> on its usage and a strict reading does not really allow it.
This has been fixed. The "From " line is explicity allowed and we
specify the "Git-compatible" format in parallel to the "Deb822" format.
> * Forwarded does not support recording it being sent to an email address.
[...]
> * Forwarded lists "yes" as a valid implicit value, but does not make it
> clear whether an explicit one should be supported.
[...]
> * Forwarded fuzzy specification means parsing its values is rather hard,
The explanation of the Forwarded field has been redone from scratch. It
has always been free form so an email address is certainly OK. We now also
have pseudo-code to decide of the status of the patch based on the various
fields.
> * It is not clear, but I think «Origin: vendor» should be clarified to
> state that the actual vendor name should be included if there is no
> other reference (such as an URL) as in say «Origin: vendor, Debian»?
Really the categorization is helpful if you have some value to put in
"Origin", if you don't have anything, then relying on the "Author" field
is probably sufficient. In any case, I added some verbiage to say that
they should ensure that the value should allow to identify the vendor.
> * For Applied-Upstream it is not easy to predict what will be the
> future upstream version that the patch will be included in. I've opted
> for stuff like «3.2.1+, commit:<id>» when 3.2.1 is the last release,
> but that does not seem optimal.
I have no solution for this. But really the version is optional, so you
could just include the commit. Or we could allow ">3.2.1" to indicate that
it's applied in versions newer than 3.2.1...
> * The git Date field could somehow be used in place of Last-Update
Done.
> * Add new metadata to track single-debian-patch autogenerated patches,
> perhaps a new «Autogenerated: yes» or perhaps better something like
> «Origin: autogenerated, by:dpkg-source» (or similar descriptive thing)?
Went for the "Origin" prefix.
> * The language could use some clarification and standardize on the field
> and stanza naming used in other parts of the deb822 ecosystem instead
> of headers and sets of headers and similar.
Hopefully this has been adressed. But I didn't want to use only deb822
vocabulary since keeping this specification understandable by non Debian
people is a worthwhile goal.
In fact, I made some reformulations to make the text more generic and less
Debian specific.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: