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

Kevin Fenzi kevin at scrye.com
Thu Jun 26 22:55:32 UTC 2014


On Fri, 27 Jun 2014 00:39:52 +0200
Sandro Mani <manisandro at gmail.com> wrote:

> So the thing that should be avoided IMO is not defining well enough
> how the procedure should work, to avoid getting swamped with patches
> which require additional work to apply. The requirement to fill out
> post a "New Package Request" style form to the bug should allow most
> of the work to be scripted, and ideally the proven packager would
> just need to look at the patch, and if happy, fire the script.
> 
> So maybe such a policy could look something like this [1]. Contrarily
> to what I wrote initially, I think it might actually make sense to
> allow also non-packagers to file such requests, and it would provide
> another way of showing off experience which will eventually lead to
> one getting sponsored.
> 
>   Sandro
> 
> [1] 
> https://fedoraproject.org/wiki/User:Smani/Trivial_Patch_Policy_%28draft%29

A few comments: 

- Not sure 'trivial' really covers the things you list in examples.
  FTBFS could be more than trivial depending on the patch. Perhaps the
  entire thing could be 'simple patches' or 'easy patches' 

- 'flags' are a pain to get bugzilla folks to add and manage. How about
  a blocker bug instead? Then interested maintainers could simply cc to
  the blocker bug to notice when new things are added. You just add the
  patch bug to the blocks of the tracker. 

- Should this be rawhide only? That would avoid 'trivial' patches that
  cause a problem from affecting users that aren't as able to debug
  them. 

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/20140626/8d9f131d/attachment.sig>


More information about the devel mailing list