On 06. 01. 20 23:27, Ben Cotton wrote:
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.
In fact, the reason I've decided to have the "at least 5 devel e-mails" part of
the policy is exactly this:
So we can identify "important packages" early and either rebuild them in time,
like Tom did for most of the listed packages (thank you!), or exempt some
packages from the policy, if good reasons exist. And here we come, working on
exactly that. I do understand that some maintainers might see the policy as a
threat, but that was never the intention.
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)
Partly, this was a compromise designed as a preemptive prevention. But OTOH it
also works around quirks like packages never being actually attempted to be
rebuilt etc.
Whether or not this is an actual problem: I've seen a lot of cases where the
bugzillas were ASSIGNED to prevent orphaning, but nothing has changed. Whether
or not this would repeat for 3 cycles is unknown to me, but I am happy that
there is a deadline. It practically says:
No, you don't need to fix this right now, you can do an explcit action to
postpone the problem, but you cannot procrastinate it forever (or forget about
it). So rather than an actual problem response, I see it as a "driven by
deadines" kind of thing.
In this thread we see that some maintainers would actually want a way to simply
get red if the the problem by assigning the bugzillas - and I prefer very much
an explicit policy exception if that is ever needed. I believe FESCo would grant
in in both the following cases:
- there is a good reason why we don't want this policy to apply on X, ever
- due to unforeseen circumstances, X isto be retired sooner than we can fix it
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?
I suggest we discuss this exception on devel list and FESCo rubber stamps it. We
can document such packages on the policy page. If the list would be so long that
it would make the policy page unreadable, it would send a signal that the policy
needs to be changed anyway.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
