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

[Kevin Fenzi]

On Fri, 27 Jun 2014 01:27:23 +0200
Sandro Mani <manisandro at gmail.com> wrote:

> On 27.06.2014 00:55, Kevin Fenzi wrote:
...snip...
> > - 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'
> Right. So the list Yaakov Selkowitz posted elsewhere in this thread 
> gives a good set of possible FTBFS causes. I'm not sure all FTBFS
> should be covered by such a policy, but if it is only a matter of
> fixing bad BRs, format security issues or makefile issues, these
> should fall under the accepted category. If the FTBFS fix involves
> porting for API/ABI breaks, then IMO that does not fall under this
> category. But yeah, simple might be more appropriate terminology.

Yeah, makes sense. 

> > - '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.
> I guess this would work just as well!
> > - 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.
> What about rawhide for all and stable releases for packagers only?

Or perhaps (since they are simple/trivial) they could be applied in
stable releases, but not pushed as updates? They would go out with the
next update the maintainer pushed...

BTW, thanks for working on this. :) 

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/ffe13e15/attachment.sig>