I've just seen:
http://kerneltrap.org/node/16680
This isn't going to be a corner case issue.
If the problem here is one of QA process having rebuilt and not rebuild time itself, what is needed here IMO is a clear case of risk management.
My view is that, even this late in the release cycle, the fix is so obvious and limited in code footprint/scope, that the question needs to be asked:
What is the chance of us introducing a regression making this change?
-weighted against-
What do we know or think will happen if we do nothing about this?
For me, considering that, I definitely feel that this is a strong candidate to be an exception to normal release rules.
I've just seen:
http:// kerneltrap. org/node/ 16680
This isn't going to be a corner case issue.
If the problem here is one of QA process having rebuilt and not rebuild time itself, what is needed here IMO is a clear case of risk management.
My view is that, even this late in the release cycle, the fix is so obvious and limited in code footprint/scope, that the question needs to be asked:
What is the chance of us introducing a regression making this change?
-weighted against-
What do we know or think will happen if we do nothing about this?
For me, considering that, I definitely feel that this is a strong candidate to be an exception to normal release rules.