Upstream First

Upstream First - Mentality

Aspects

• Code
• Testing
• Packaging

How this applies

• If you have a patch there is almost no reason that a patch should not be submitted upstream(master/backport)
• If you find a bug and a fix for a downstream issue. 
• If you have a packaging change there is almost no reason that a patch should not be submitted upstream

Examples:

• If you have a patch that you are backporting downstream.  The patch should be at least proposed and merged to master.  If master is merge, it should be proposed to stable branches (even if it won't be accepted to upstream, then add that a comment or in the commit message as a concern) .  It may be abandoned but that is fine.
• If there are packaging differences or bugs between downstream and upstream, you should propose patch to upstream packaging to reduce differences in packaging.
• If you have a new feature the test code should be in the upstream code, packaging should have any new requirements, and CI should be exercising the new feature before it can be considered complete.
• If you find a bug, make sure the bug is valid, check to see if it has been reported upstream? File it upstream, work it upstream, fix it upstream.  But if you are needing to fix something for a customer for an escalation, do what you need to but also follow up with upstream and make sure it's patched.