[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1028503: UDD: Unknown "yes" value for Forwarded field in patch metadata



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


Reply to: