Patch management: tracking forwarded status

[Dominic Hargreaves]

[this started off as a wishlist bug to add a new maintainer test, but
it may be better to separate policy discussions from technical details].

We have for a long time operated a policy (unwritten except possibly
in <https://wiki.debian.org/PerlMaintenance>) that patches which aren't
genuinely specific to Debian shouldn't be applied without being forwarded
upstream. This is to ensure we don't end up with an increasing burden
of local patch maintenance, and also so upstream finds it easier to
support our packages (knowing the deviation from upstream is minimised).

To this end we have fixes/ and debian/ patch directories. My understanding
of this has been that anything potentially portable upstream should live
in fixes/ and only things genuinely specific to debian/ should go in
debian/. Recently we had a few patches we wanted to get in promptly and
to mark the fact we hadn't forwarded upstream we put them in debian/.

Was this the correct thing to do? My general workflow for patch review
is to assume I don't need to worry about tracking the status of upstream
acceptance with anything in debian/, and that's no longer true.

I would quite like to see some tooling to help us here. A maintainer
test to report on patches which haven't yet been forwarded upstream
on patches in fixes/ would be nice. We would need a way to positively
assert that we're deferring the forwarding, for those cases where it's
not appropriate to forward upstream before a release. Perhaps a new tag
Forwarded-Reason? That would be either a textual note, or (preferably)
a URL pointing to a divergence tracking bug report such as #762269[1].

The logic[2] for patches in fixes/ should be:

if Forwarded == 'not-needed'
 fail # should be in debian/ instead
else if Forwarded = 'no' and Forwarded-Reason is null
 fail # should justify why we haven't forwarded it yet
else
 pass

The logic for patches in debian/ should be:

if Forwarded != 'not-needed'
 fail # should be in fixes/ instead
else
 pass

It would then be much easier to see at a glance the status of our
upstream contributions.

Thoughts?

Dominic.

[1] There doesn't seem to be a documented procedure for revising a DEP
    once it's been accepted, even in a backwards-compatible way, though.
    But maybe the right thing to do is just to use new keywords anyway.
[2] Note that if Bug is not null, Forwarded is implicitly yes