On Mon, 7 Dec 2015 10:53:32 -0700, Kevin Fenzi wrote: > So, what you would like would be: > > a) If you have autokarma set and the update doesn't reach autokarma, > push it automatically when it reaches the timeout. With a customisable timeout, it would be a good feature. > b) Have another bodhi setting for 'push automatically when reaching the > 'maintainer can now push to stable' time limit. (defaulted on or off?) Not so good, because the current blocking period seems arbitrary. 14 days? 7 days? Why? It's a rather short period (considering that it can take days for a mirror to pick up new packages) and doesn't give all testers enough time to notice the test update and test it painstakingly. > > What's needed is software developers and policy makers to agree that > > some areas are problematic, and to agree on ideas and an agenda. To > > agree that the karma system is flawed and things like testers > > ignoring past votes and overriding another's -1 with their own +1 > > should not be possible. > > I don't think I agree with that as a blanket statement. What if the > person who added -1 is just wrong, or you cannot duplicate the exact > problem that they said the update had? I wrote "testers _ignoring_ past votes", not testers disagreeing with each other explicitly in their votes _and_ comments. Who decides whether a person is wrong? And why can't such a decision not require somebody to explicitly mask/override a wrong -1? As it is so far, there are fights between people voting +1 and -1 like it would be some sort of package popularity contest, and not even in the comments the people refer to eachother being "wrong". Then, when adding a comment and pointing at the QA feedback guidelines, people admit that they haven't been aware of those guidelines. > > How many layers of extra work do you ask for? Imagine that a fix is > > from upstream or has been applied and released upstream already. What > > extra testing and baby-sitting is needed at Fedora's side even for > > entirely new packages? > > What would you propose? A release process that makes sure that published updates (in particular security fixes) reach the stable updates repo in adequate time. > Ship the update directly to stable because upstream oked it? Shipping directly into stable could be the right thing in _some_ cases. Such as packages that never receive any tester feedback in bodhi. I don't see why you would want upstream to ack any updates. If upstream is not explicitly interested in Fedora's packages, there is no interest in testing updates either. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
