On Fri, 27 Jun 2014 11:55:37 -0400 (EDT)
Miloslav Trmač <mitr(a)redhat.com> wrote:
That’s only in some ideal case where we can get all the manpower we
might need.
Adding a non-upstream patch to a package by a non-owner of the
package essentially commits the owner of the package to either push
the patch upstream or to keep rebasing it on top of the upstream
releases; something the package owner, based on past practice, didn’t
sign up for and might never have time for.
It seems strange that we would be willing to impose such non-optional
work on a package owner for a patch someone could have just as well
sent upstream, when we don’t even impose such non-optional work on
the package owner for things they are directly responsible for and
have no other upstream, such as updating the package to follow
changes in packaging guidelines.
That’s not to say that Fedora should never have non-upstream patches,
nor even that provenpackagers should never apply non-upstream
patches, but drive-by-patching by people who are not on the hook for
long-term mainteinance should IMHO _strongly_ default to submitting
patches upstream first or instead. Mirek
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).
There's a lot of different cases here...
kevin