Michael Schwendt wrote: > Then with the switch to koji+bodhi a few package owners complained loudly > about false positives that were caused by pending builds, which were not > found in the master repo yet. A few other package owners jumped upon the > train and questioned the usefulness of the script, since they were of the > opinion that breaking upgrade paths the way they did it with > updates-testing and stable updates would not be considered a problem. The actual issue we complained about was that the script (the one querying Koji) required Fn+1 updates to be >= Fn updates-testing which makes no sense at all. I wrote a patch to fix that: http://repo.calcforge.org/f10/check-upgrade-paths.py.diff but it got lost under Jesse Keating's endless pile of TODOs. :-( And it seems the whole code is going to be rewritten for autoqa now and nobody cares about having a working check-upgrade-paths.py until autoqa goes live. :-( > It's also simply a crap decision if packagers quickly mark F10 updates as > stable while the corresponding F11 update has not seen any testing at all > (while it's stuck in the growing list of pending updates in bodhi or > waiting for release of F11). In my experience, an update which is working fine on one release has a very high probability of working just as well on the other ones, especially if the package being updated was working in the first place (which are the cases we really care about - if the package was broken, pushing an update which is broken the same way doesn't make things worse). In the updates I pushed, I only remember one case where it didn't, which was due to improper use (string comparison instead of numeric comparison) of dist conditionals (by another packager, who requested that update to be added to our update set, I'd have never made that mistake myself, though I am to blame for not proofreading the changes). Due to bad timing, that build hit stable directly (it got added to our Qt 4.5.0 update set just before we decided to finally push it to stable after a long time in testing), causing a broken dependency on F9 (which I fixed in the next push). But this was an isolated occurrence which was due to a blatant packaging mistake (which could even be caught by automated QA - any spec file containing "%{?fedora}" with the quotes is broken) and which a maintainer experienced with multi-release updates won't make. So I don't see pushing identical updates built from identical specfiles for 2 or 3 releases at the same time as evil at all. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
