I wanted to highlight this issue as it appears to be a serious violation of the update policy.
A couple of weeks ago, a dracut update for F20 was submitted, and last week it went stable:
https://admin.fedoraproject.org/updates/FEDORA-2014-4704/dracut-037-10.git20140402.fc20
note the previous stable build of dracut was https://admin.fedoraproject.org/updates/FEDORA-2013-23326/dracut-034-64.git20131205.fc20.1 , an appropriately handled minimal update to the build we shipped with F20, dracut-034-64.git20131205.fc20 .
The new update absolutely does not appear to be an appropriately handled, minimally-targeted update, as the updates policy requires:
"As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience."
"This necessarily means that stable releases will not closely track the very latest upstream code for all packages. We have rawhide for that."
As the NEVR and git history for the dracut-037-10.git20140402.fc20 build make clear, this is not a bug fix update to dracut-034-64.git20131205.fc20.1 , but a simple dump of four months of unfiltered upstream master branch development. This is entirely inappropriate for an update to almost any package in a stable release, never mind a package as critical as dracut, which can very easily render systems unbootable.
And indeed, this new build has broken multiple systems: I'm aware of at least https://bugzilla.redhat.com/show_bug.cgi?id=1084766 , which is bad enough, and there may be others.
I'd like FESCo to do what it can to ensure #1084766 is fixed as soon as possible, communicate to the maintainer of dracut in the strongest possible terms that this kind of behaviour is unacceptable, and require the maintainer to provide a comprehensive evaluation of changes between the two package builds so we can proactively attempt to resolve any other regressions the new one may have introduced (or other appropriate action, such as an epoch-bumped downgrade back to the old code plus targeted bugfixes or something like that).
I do apologize that QA didn't catch this update and prevent it going stable, we should have spotted it.
If you look at bug https://bugzilla.redhat.com/show_bug.cgi?id=1081841 you will see that it was noted that this change in rawhide was potentially going to be a problem for people upgrading from Fedora 20, before the related update in Fedora 20 went to stable. So QA did provide an early warning of potential issues, but unfortunately didn't prevent the f20 update from going stable.
Fesco agrees this is not ok, needs to be fixed, needs determining what else might be broken, and should not be allowed to happen moving forward. (+7,0,0)
as harald did not respond in any way (it's possible he's on vacation, but we can't tell) I went ahead and took action to fix the bug myself; there's an update in u-t - https://admin.fedoraproject.org/updates/FEDORA-2014-5509/dracut-037-11.git20140402.fc20 - which should fix it (needs karma). The larger issues stand, though (and obviously I'd like Harald to review my change and make sure it's correct, and point up any other major changes that could cause problems).
FWIW, I followed up. Harald has been on PTO.
Login to comment on this ticket.