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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
