On Wed, 2018-03-07 at 14:43 -0500, Randy Barlow wrote:
> On 03/06/2018 07:20 PM, Adam Williamson wrote:
> > Removing it is one choice, sure. Looking at those ideas again and
> > deciding if we want to actually go ahead and implement any of them is
> > another choice.
> Cool thanks for the history there. I actually think those ideas sound
> pretty cool and I'd +1 getting them in place (though I really can't
> personally do it soon because F28 but patches welcome).
> Do you think the ideas require a separate karma feedback though? What if
> we did the ideas you talked about in response to a regular -1 on a
> critpath package? I.e., just the same karma button that we use for
> normal updates, but on critpath updates the alarm bells are bigger?
There's two problems with that:
1) The critpath can be broken by non-critpath packages, because our
critpath definition is really not *close* to correct. It's just a list
we made up one day and have not done a great job of updating since. It
is not in any way 'validated'. Until recently, it didn't have bash,
setup or selinux-policy in it, for instance.
2) Critpath packages can be broken in ways that don't break the
critical path. selinux-policy is a great example there, in fact; a -1
for an selinux-policy update *could* mean "this update renders all
systems unbootable", or it *could* mean "this update broke some obscure
leaf package two people are running".
> If we do think there's a good reason to keep two kinds of karma for the
> glorious feature, perhaps we could just hide the critpath karma feedback
> buttons in the UI for now just so they don't get confused with the
> normal karma, which can lead to some issues since it doesn't really do
That sounds reasonable to me indeed.
> Or another easy thing I could do server side is autodetect
> someone setting critpath karma to -1 and forcing their karma to also be
> -1 when that happens.
Also seems reasonable.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org