Open Stack

Day, Phil wrote:
> Would be nice in this specific example though if the actual upgrade impact was explicitly called out in the commit message.

Yes, UpgradeImpact should definitely also elaborate on the exact impact,
rather than expect the reviewer to deduce it from the patch.

> [...]
> So it looks as if UpgradeImpact is really a warning of some change that needs to be considered at some point, but doesn't break a running system just by incorporating this change (since the deprecated names are still supported) - but the subsequent change that will eventually remove the deprecated names is the thing that is the actual upgrade impact (in that that once that change is incorporated the system will be broken if some extra action isn't taken).    Would both of those changes be tagged as UpgradeImpact ?  Should we make some distinction between these two cases ? 

This is a bit of a corner case (deprecated options), but I feel that
UpgradeImpact is warranted in that case. It's good that people caring
about upgrades to be warned of deprecation *and* removal, even if
deprecation is technically not triggering an upgrade issue (yet).

I don't think we need to distinguish between the two cases. Both are of
interest to the same population.

-- 
Thierry Carrez (ttx)