On Mon, 30 Jan 2017 00:53:05 +0100 Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > Hans de Goede wrote: > > Well, that is a fix, but the real problem is that either the new > > libglvnd enabled mesa should not be in updates-stable and thus not > > in the buildroot; or both the new libglvnd enabled mesa and the new > > libglvnd should be in updates-stable. > > This is the result of 4 very poor decisions, by different > people/groups: > > 1. the decision to enable libglvnd in an update to a stable release. > IMHO, such a change is totally unsuitable for a stable release update > and should have been done in Rawhide only. Perhaps so. I agree it definitely shouldn't have been pushed without fixing all the packages that are broken by the update. > > 2. the decision to block Bodhi pushes on ostree failures. Without > that, Bodhi would not have been stuck for days with all updates > locked and this fiasco might possibly have been avoided. If the > ostree compose fails, the Bodhi push should just proceed with an > empty or old ostree directory (whatever is easier to implement). > Rarely used experimental delivery methods should not hold the entire > distribution hostage. I disagree with you here. I think ostree is important and people are using it. However, there's two (IMHO better) ways forward here. First we could (and should) just back out rpm-ostree/ostree/bublewrap/whatever updates breaks composing and debug it on the side. Second, the atomic sig is looking at changing how the updates stream is made and only push it every 2 weeks. That would remove it from being done by bodhi. > 3. the decision to use autokarma. This is just yet another broken > update that went stable due to autokarma. Autokarma is an absolutely > unacceptable practice and should not be allowed. All push requests > should be issued by a human after reviewing the status. I disagree. If autokarma wasn't used then the update could well have been pushed again after the maintainer saw that it was able to be pushed. Also, it would result it a bunch of updates stalling in updates-testing as maintainers forget to push things stable. Also, it would result in maintainers spending a bunch more time looking at things and seeing... that they are all ready to go to stable. > 4. the decision to disallow direct stable pushes. The right way to > fix the issue quickly, limiting the damage once done, would have been > to push libglvnd directly to stable. But Bodhi won't allow that. > Direct stable pushes are an essential mechanism to fix regressions > and to limit the number of affected users by minimizing the exposure > time to the regression. I disagree again. Right now, mesa in stable updates has a broken dep. dnf and gnome-software will not update it because of that. So, right now, no stable updates users are broken, they just see an unsightly broken dep on trying to update. If we push libglvnd to stable right now, everyone will be able to update mesa and it, and all users of sway will get a black screen and be broken. So, we should _not_ push libglvnd until sway is fixed. kevin
Attachment:
pgpdvvFXAuEtQ.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
