> > Do you have some other ideas/proposals, in general or in some specific > > situations regarding the slip length? > > > I'm wondering if there would be interest in hosting a file containing > upgrade requirements for each version. For example it could have the > package version requirements needed for a successful upgrade. The > upgrade tool could check that and warn the user. >From the blocker bug process perspective, I think this doesn't change much. Instead of ensuring the updated build is pushed to FN/FN-1/FN-2, we would need to ensure this requirements file is updated and pushed (probably as part of the system-upgrade package). So, the same process for us, really. This would allow us to provide a better experience for important bugs which were not approved as blockers, though. If this definition file contained a package version that is not found (this or later version) while computing the system upgrade, system-upgrade could visibly warn the user that this and this bug still affects the upgrade process and reviewing those is recommended before commencing. Basically this is the same we do in Common Bugs [1], but visible to every user, not just those who stumble upon Common Bugs. I'd like that. But this case is not really related to the blocker bug process and this particular proposal and should be suggested as a feature request to system-upgrade developers. (I'm somewhat skeptical that Will will want to maintain this functionality, even though it would be nice for users. But maybe system-upgrade could simply suggest users to look at the Common Bugs page? That sounds simple enough and maintenance-free.). So overall a nice idea, but I think it does not directly affect any of those two decisions we need to make. But maybe I missed something :) [1] https://fedoraproject.org/wiki/Common_F23_bugs#Upgrade_issues -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
