On Mon, Jan 6, 2020 at 4:58 PM Peter Jones <pjones@xxxxxxxxxx> wrote: > > On Mon, Jan 06, 2020 at 12:54:58PM +0100, Miro Hrončok wrote: > > > Regardless of different opinions about aggressiveness, having policies > > and no enforcement makes no sense. Either the polices are too > > aggressive and we need to change them, or they are not and we need to > > enforce them. > > That seems like a rather poor way to think about policy in general, and > I have some disagreements with it in this specific case as well. In > general, you're not considering that it may be worth having policies > reflect our *ideal* situation, and acknowledge that they don't always > fit the real world precisely. > I agree with both of you here. I'm a big believer in the "don't have rules you're not willing to enforce" philosophy, but I also think "zero tolerance" is a bad approach to things. The challenge we face here in particular is how to strike the right balance. Strict enforcement is the easiest to scale because it can be largely automated. The problem is that we run into these non-ideal cases and don't have a good way to handle them. A more hands-on approach would be better, if we had a person whose full time job was to go through the output and identify what is and is not appropriate to remove. Everyone here is acting in what they see as the best interests of the community. On Mon, Jan 6, 2020 at 6:34 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > This is part of the policy to prevent maintainers form simply ASSIGNING bugs > forever without fixing anything. > How much of this is a response to an actual problem versus a preemptive prevention of an anticipated problem? If we were to allow maintainers to set bugs to ASSIGNED forever, is the actual end result something we could live with? (Perhaps with an exception for security bugs) Similarly, to Peter: how would you suggest we special-case these three packages (and others like them) so that we know to always exclude them from the mass rebuild (except when explicitly requested) and exempt them from the automated FTBFS queries? -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
