Re: RFC: DEP-3: Patch Tagging Guidelines

[Felipe Sateler <fsateler@gmail.com>]

Raphael Hertzog wrote:

> Hello,
> 
> please find below a first draft of DEP-3 that I called Patch Tagging
> Guidelines. The idea is to standardize a set of meta-information to embed
> in patches that we apply. Please review, share your comments and ideas of
> enhancements.

If the idea is to standarize metainformation, I would suggest standarizing 
filenaming scheme too. What I do in some packages is to name the patches as 
follows:

0xxx-name.patch  -> Grabbed from upstream VCS
1xxx-name.patch  -> Interesting for submission upstream
2xxx-name.patch  -> Debian-specific

The Status field is then no longer needed, since patches in 1xxx should be 
moved into 0xxx when accepted upstream, or into 2xxx if rejected for non-
cosmetic reasons (ie, the purpose of the patch is not accepted, not just the 
current form). This has the added benefit that patches submitted upstream 
have a greater chance of applying cleanly against the current HEAD of 
development. The Origin field becomes optional too.

<snip>
> 
>   * `Status` (optional)
> 
>     This field is a textual explanation of its status concerning its
>     inclusion in the upstream project. The first line should consist of a
>     single keyword among "&lt;vendor&gt;-specific" (the patch must not be
>     forwarded as it is specific to a vendor, ex: branding patches),
>     "must-be-forwarded" (nobody has taken the time to forward the patch
>     yet), "forwarded" (the patch has been forwarded, the Bug or Patch
>     fields should contain the corresponding URLs) or "rejected" (the patch
>     has been submitted but it has been rejected upstream). Supplementary
>     lines can be used to explain in more details the status of the patch.
>     It should be used for example to explain why the patch has been
>     rejected, or why this change is only meaningful for the vendor.

This field misses a value for patches picked from upstream VCS.

<snip>
> Interpretation
> --------------
> 
> In the analysis of the meta-information, a certain number of related
> facts can be deduced from the absence, presence, or combinations of fields
> and their values.
> 
>   * Has the patch been forwarded upstream?
> 
>     If there is a `Status` field, its value answers the question.
>     If there's an `Origin` field and it contains "upstream" or "backport",
>     the patch comes from upstream and it doesn't need to be forwarded.
>     The same is true if there's a `Commit` field.
>     In other cases, if there is a `Bug` field, then the patch has most
>     likely been referenced in the bug and upstream should know about it.
>     Any package maintainer should ensure that the existence of the patch
>     has been documented in the upstream bug log when he adds the
>     patches' meta-information.

I think answering a simple question (and one of the most likely to be asked 
about a patch) should be done by a simple rule. The Status field should be 
sufficient for this. Introduce a picked-from-upstream value for the Status 
field and then we are done.


-- 
Felipe Sateler