Drawing lessons from fatal SELinux bug #1054350

Kevin Kofler kevin.kofler at chello.at
Sun Jan 26 13:54:46 UTC 2014


Reindl Harald wrote:
> 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

Even just doing that would be an improvement, but I still think the whole 
karma system should go away entirely and the maintainers should have the 
call.

> 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

I totally agree that the maintainer should be the one making the call! 
That's why I want the karma stuff removed. :-)

What's the point of keeping that number if we drop the silly Update 
Policies? Shouldn't the maintainer actually READ the comments instead of 
basing the decision on an arbitrary algebraic sum of unweighted +1 and -1 
terms?

> 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

+1

        Kevin Kofler



More information about the devel mailing list