Hi, On 12/01/23 at 01:57 +0100, Guillem Jover wrote: > Hi! > > The new patch data is great, thanks!
Thanks! > I just noticed though that it does > not recognize a "yes" value for the Forwarded field, while the > "Patch Tagging Guidelines" has this to say about it: > > * Forwarded (optional) > > Any value other than "no" or "not-needed" means that the patch has > been forwarded upstream. Ideally the value is an URL proving that > it has been forwarded and where one can find more information about > its inclusion status. > > If the field is missing, its implicit value is "yes" if the "Bug" > field is present, otherwise it's "no". The field is really required > only if the patch is vendor specific, in that case its value should > be "not-needed" to indicate that the patch must not be forwarded > upstream (whereas "no" simply means that it has not yet been done). > > So it says that any value other than "no" or "not-needed" means > forwarded, then it says that if the field is missing it means it is an > implicit value of "yes", where I've always interpreted as implicitly > stating that "yes" is also a valid value. If the field is missing, then its implicit value is 'yes' only if the Bug field (which points to the upstream bug) is present. > (I also recently amended the patch metadata header template generated > by dpkg-source and did not have "yes" as a value there, but I've added > it locally now, and will probably queue it for dpkg 1.22.x.) The logic in the UDD implementation is documented just below the table: > The forwarded value in the table is computed and might differ slightly > from the original DEP3 specification. It is yes only if an URL is > provided as value. It is invalid if none of the other value could be > determined with certainty (yes, no, not-needed). But I could do better, and consider the Bug field in the analysis. The problem I have is that the 'Bug' header is often misused, and used for the Debian bug instead of the upstream bug. But I could special-case that. Lucas
