On Fri, 27 Jun 2014 01:27:23 +0200 Sandro Mani <manisandro@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
