Drawing lessons from fatal SELinux bug #1054350

[Reindl Harald]

Am 25.01.2014 22:00, schrieb Kevin Kofler:
> But then the right solution is to disable karma automatism entirely, not to 
> set it to some ridiculously high value.
> 
> Those meaningless thresholds need to go away (and really, the whole concept 
> of Bodhi karma and the policies that depend on it)

i am not entirely sure how that is meant

* disable the automatism to push to stable
* forget the whole karma system at all

in case of "disable the automatism to push to stable" i agree

in my opinion karma is a indication for the maintainer but not
the decision - the karma has to be handeled differently for the
same package and different updates and only the maintainer can
decide that *as person*

why?

because it depends on the change itself

speaking with my developer hat on: there are updates on software
inside our company where i do not hestitate a single seconds deploy
the new CMS version to some hundrets of customers without tell anybody
there was a update at all because *i know* there can be no bad impact

on the other hand there are updates and changes which needs to prepare
any singel webhost, rollout a small update to prepare the real one by
add database colums not used currently but need to be there in the time
window files are replaced and database scheme can be updated

the second case is for not have any single request going wrong

and there is another category where all the work above has to be done
and tested thousands of times but still need a "keep your eyes open"
after it is done because you can't test and verify every single action
a complex software may do with every possible input data



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140125/96d78375/attachment.sig>