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

[Simone Caronni]

+1 from me!
On Jun 26, 2014 5:51 PM, "Sandro Mani" <manisandro at gmail.com> wrote:

> Hi,
>
> From time to time, I see trivial patches posted in bugzilla which end up
> sitting there because the maintainer is too busy / gets bombarded with tons
> of bugzilla mails and misses that particular one / whatever reason. As a
> packager, sometimes it seems very hard to get such trivial patches applied.
> What you can do is
>
> - You can keep pinging bugzilla
> - You can apply for commit rights, which might be excessive for just this
> one patch, and still requires the maintainer to answer.
> - You can start the non-responsive maintainer procedure, even if you know
> perfectly well that the maintainer is still active. Or you might suspect
> that the maintainer is inactive, but you'd rather not have to wait for an
> entire month, because this one bug is blocking your work.
> - You can start asking on irc for a proven packager to jump in and hope a
> proven packager is online and has time at that moment.
> - You can post on -devel, though again, unless someone has time right now
> it gets forgotten an people move on.
> - Repeat the above n times until someone shouts at you and flags your
> email as spam :)
>
> So wondering, if there is a way we can improve the situation. One idea
> which comes to mind would be something like "trivial patch policy"
> - after i.e. one week of inactivity one can flag such a bug as a trivial
> bug. You can only do so if you are a packager and post a patch (which also
> updates the SPEC, so just a matter of apply patch, fedpkg commit & build).
> - for anything else than packaging issues, the patch may only be a well
> justified upstream commit backport
> - a proven packagers gets notified about the issue, validates the patch
> and if ok fires the update. The entire thing might work similar to how a
> New Package / Package Change request works, by posting something like this
> to the bug:
>   Trivial Patch Request
>   =====================
>   Patch[branch]:
>   Patch[other_branch]:
>   Reason:
>   Upstream commit:
>   Submitter:
>
>
> From my experience such situations do not occur too frequently, but when
> they happen, they can be hard to deal with.
>
> Comments?
>
> Thanks,
> Sandro
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140626/af4f3061/attachment.html>