On Sun, 6 Dec 2015 21:47:24 +0100, Reindl Harald wrote: > > And as you are not a package maintainer at Fedora, it could be that you > > underestimate the amount of burden/bureaucracy that's considered > > unnecessary by many packagers > > explain me the burden/bureaucracy in the countless cases where > "fedora-easy-karma" shows the status "this update has reached... and can > be pushed to stable when the maintainer wishes" other then just press > the button Let me try. Not specific to the Yum update you refer to in the original post, and I don't know for how many updates the "autokarma" and critpath settings have been lost upon migration to bodhi 2. => There are some strange status messages in some of the tickets, such as very late +1 critpath votes. Packager spends time on preparing an update for multiple dist targets, test them locally, builds them within koji and waits for the builds to become available in bodhi. Packager submits the update and related bugzilla ticket numbers in bodhi and either keeps the default karma threshold or adjusts it. For non-critpath updates, some packagers enter a threshold of +1/-1 to reduce testing requirements, but a single pet peeve reporter, who votes -1 due to a problem that exists for a much longer time already, can cause the update to be withdrawn automatically. So, some packagers go with +1/-3 for example, requiring a +1 from a single tester while still making it possible to pull the update, if breakage is found by three testers. After adding the updates to bodhi, packager wants to be done and wants to move on to other tasks, since the update would be pushed automatically *if* testers gave the required number of +1. Some of the votes could come from the bug reporters, who are notified about the update inside their bugzilla tickets. [I've pointed out that they are notified too early.] [Packager knows that if an update for an older dist is published earlier than an update for the current dist, this can lead to breaking dist upgrades. Disabling karma based auto-pushing currently is the only way to avoid that. More work, and reoccuring tasks to do manually aren't good.] However, since the packager wanted to rely on karma based auto-pushing, the email notification "This update has reached X days in testing and can be pushed to stable now if the maintainer wishes" may come too early, especially if the karma level has not been reached. The packager would need to load the bodhi page linked in each of the notifications and decide again whether to push manually without waiting for testers. Does the packager want to push manually at that point? Sometimes. Not always. You expect packagers to review all their bodhi tickets everytime they receive a nagmail from bodhi, and then to decide again whether to wait for testers or whether to push manually without any prior feedback. That doesn't scale for everyone. The list of active updates inside the web ui can grow easily, too. Let's say you start reviewing your updates for F23. You decide to push an update after 14 days and 0 karma, because you want to get it out as quickly as policies allow. You must not forget the corresponding update for F22. It has received a +1 and a -1 but has not reached -3 yet to unpush it automatically. It may have been a better idea to unpush the updates for all dists manually upon receiving the -1. But then what's the point of a -3 threshold? And it also requires you to pay attention to every bodhi mail you receive and take action immediately, or else the messages about later votes and status changes may pile up quickly. While waiting for updates to be pushed, the packager also needs to be careful not to submit further updates. Bodhi used to be able to obsolete older test updates automatically, which may be the wrong thing to do in all cases (the new update may not be as good as the current one and may require increased testing). What would some packagers prefer? A way to append updates into a queue and _be done_ unless a tester intervenes, and if all goes well, the update gets published either after positive feedback from a minimum number of testers _or_ after a grace period of N days sitting in updates-testing. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
