> Do you have some other ideas/proposals, in general or in some
> 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 , 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
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 :)