Patches for trivial bugs sitting in bugzilla -> trivial patch policy?
kevin at scrye.com
Fri Jun 27 03:16:33 UTC 2014
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:
> > - 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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the devel