Drawing lessons from fatal SELinux bug #1054350
mschwendt at gmail.com
Sat Jan 25 21:25:59 UTC 2014
On Sat, 25 Jan 2014 22:00:02 +0100, Kevin Kofler wrote:
> Right, but you were proposing to wait until it reaches a karma of +16.
Certainly not. That Yum update is only a good example where a high
karma threshold has been reached in less than a week, and even without
a vote from all available/active testers. Sure, Yum is widely-used, which
cannot be said about niche-market packages.
I'm proposing that Test Updates are offered for a minimum duration
to allow for the time it takes to push them into the repo *and*
be picked up by world-wide mirrors. That increases the chance that
available testers get a chance of evaluating an update and giving
feedback _before_ it gets marked stable because of reaching +3 very
early (based on koji downloads, for example).
That has worked rather well for the more interesting update with a karma
threshold of 5: https://admin.fedoraproject.org/updates/FEDORA-2013-22706
The -1 votes have not been too late.
On the contrary, if a tester is available and finds a bug in a new
update as offered on a nearby mirror, but in bodhi the update has been
marked stable in less than a day already or has skipped updates-testing
even, the tester cannot help anymore. That's a case that would be
> > It could be that nobody uses the package at all, so it would not a big
> > deal if an update (or upgrade?) took 7+ days to enter the updates repo.
> > ;-p
> But then the right solution is to disable karma automatism entirely, not to
> set it to some ridiculously high value.
Yes, debatable. But we shouldn't argue about it. '5' or '10' for Yum
updates isn't ridiculously high while still giving testers the opportunity
to vote cleverly and trigger the automatic push.
More information about the devel