On Fri, 27 Jun 2014 01:27:23 +0200
Sandro Mani <manisandro(a)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