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

[Kevin Fenzi]

On Fri, 27 Jun 2014 11:55:37 -0400 (EDT)
Miloslav Trmač <mitr at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140627/b202459e/attachment.sig>