[RFC] Require Upstream Notification before Downstream Patching

[David Woodhouse]

On Fri, 2022-03-04 at 15:40 +0100, Paul Spooren wrote:
> I recently got an email about the _annoyance_ that OpenWrt handles
> downstream patches without upstream ever seeing those. While this
> probably makes sense for some cases, it may result in users reporting
> issues upstream which were introduced by our own doing.
> 
> Should we make it a _hard_ requirement that whenever people want to
> add downstream patches to OpenWrt, a reference to their honest
> attempt adding the patch upstream is needed?


There are times when we know that we have a local hack that isn't truly
viable upstream, and we don't want to *make* people post something like
that just to appease our policy.

What has worked well in other contexts is to start simple: Only require
that the submitter explicitly *state* the upstream status of the patch:
ideally a link to the upstream submission or commit ID, but it's
acceptable to have a coherent explanation of *why* the patch isn't
upstream.

Where we have patches as patch *files*... which OpenWrt does... we can
also require an Upstream-Status: header in the file itself, along with
the Signed-off-by: and other metadata, which gives this information
(unless there's a 'cherry picked from ...' which is a perfectly viable
alternative *if* it's a cherry pick from upstream or a stable kernel).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-adm/attachments/20220304/50cd85ac/attachment.p7s>