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

[Guillem Jover <guillem@debian.org>]

On Thu, 2023-01-12 at 12:05:51 +0100, Lucas Nussbaum wrote:
> On 12/01/23 at 01:57 +0100, Guillem Jover wrote:
> > 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.

Sure, the point I was trying to make is that when the field is present
it is stated that any value (other than "no" or "not-needed") is
considered to mean it has been forwarded. And as I had the perception
that you might be trying to be strict on the values accepted, I was
trying to argue that because the value "yes" is mentioned (with quotes,
so I interpret it as one more of the "known values" even if referred
as an implicit value), then when the field is present it should also
be accepted with such "known values".

I otherwise do not know how we can mark patches as forwarded when
for example you send them directly to upstream via email or to a mailing
list that has no public archive or similar.

> > (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).

I'm wondering why diverge from the patch metadata guidelines? If there's
a desire to change the field semantics, perhaps it would be better to
change the guidelines instead? :)

But given this interchange, perhaps we should try to make it more
clear or explicit about some of these aspects there!

> But I could do better, and consider the Bug field in the analysis.

I think the Origin field needs to be taken into account too, in
particular when it has an "upstream" or a "backport" value. As well as
the Applied-Upstream field.

> 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.

Sure, if the Bug field is misused I see no problem with flagging it as
erroneous.

Thanks,
Guillem