Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Sandro Mani]

On 27.06.2014 18:56, Kevin Fenzi wrote:
> Well, I think you are talking here about a patch that changes the code
> of the package. Many of the cases people were talking about for these
> 'trivial' or 'simple' patches didn't even touch the code... they simply
> modified the spec, so have little to do with upstream (unless they also
> want to apply the fix to any spec they have).
>
Indeed, I think this would be interesting mostly for issues concerning 
the packaging aspect, not the code itself. The biggest exception to this 
are FTBFS issues, which may in certain occasions indeed touch the code, 
but usually the fix only requires generic knowledge of the respective 
programming language, not specific knowledge of the software package. 
For anything that touches code in a non-trivial way, I'd make it 
mandatory to have the code upstream first, to avoid a) the patch staying 
downstream forever and ending up being a burden to the maintainer and b) 
to ensure at least one pair of expert eyes looked and approved the code.

So to summarize, what should be accepted:
- Spec and build script changes for the following cases:
  * FTBFS issues
  * clear mistakes which causes issues for other packages
- Changes to the code:
   * In case of a FTBFS, only generic, trivial changes (format security 
changes would be an example)
   * In other cases, only small patches to fix specific serious problems 
(crashes, incorrect behavior), and *only* with an upstream commit.
* Changes to fix obvious distribution integration issues (i.e. desktop 
file with missing icon): such fixes might require changes to the spec, 
to a non-upstream source, or to the upstream source. In the latter case, 
the changes must be accepted upstream first.


Sandro