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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
