On Sun, 19 Jan 2014 20:03:14 +0100, Reindl Harald wrote: > this case is *very* special because you also need to realize *what* > update before breaks the scriptlets and that it break all scriptlets > > zero chance to figure that out for 99 out of 100 users > > you only need to look at the amount of reports that other packages > seems to be broken to get the picture True. However, it's not the Fedora product's users who do the testing, but brave testers with updates-testing enabled, who evaluate packages _before_ they get pushed into the stable updates repo. All the "ordinary" users, who thought that the nfs-utils update contained a bad scriptlet, assumed that such a bug has slipped through the Fedora testing process. What does that tell about quality of Fedora testing? ;) Other users have reported the same issue for "initscripts" and other packages. What these people have in common is that they have noticed the scriptlet errors and have opened a ticket in bugzilla. IMO, testers would have noticed it too, if the test update had been offered in the updates-testing repo for a longer time. It simply won't work well, if testing is a race for the fastest +1 votes. I wonder what a tester would have done when encountering a scriptlet error, if the bad selinux package had not been marked stable yet? Would it have led to a -1 on the wrong package? The nfs-utils update has been pushed to stable with +3 one day after the bad selinux policy. > that case seems to be unavoidable without force every packager of > critical path updates to test them manually before they appear in > updates-testing and on bodhi at all and to catch the specific case > push the updates to testing after at least on their machine a > independent update was applied without problems - unlikely to happen Why that? Why the manual installation? There is no need to rush when voting in bodhi. Such a selinux policy update with many changes is _scary_. Come on, Fedora 20 has been released already after a long development/testing cycle. Why take the risk of breaking it with large updates that are rushed out? Where the released product is broken already since day zero, a few more days of testing the fixes don't hurt. One of the fundamental actions that "critical path package" updates must be able to complete is """get updates""". That means that after a full "yum -y update" to fetch a latest batch of Test Updates, the tester must attempt at triggering further system updates. A downgrade of some packages may be enough to test a subsequent manual "yum update", at least. Alternatively, wait for the next updates/test-updates to appear in the repos, but what about automatic updates and update notifications?. Good, if Yum still works, at least. But that doesn't mean testers should neglect the graphical package tools and system update mechanisms many other users will depend on. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
