Would be nice in this specific example though if the actual upgrade impact was explicitly called out in the commit message.
>From the DocImpact it looks as if some Neutron config options are changing >names - in which case the impact would seem to be that running systems have >until the end of this cycle to change the names in their config files. (Is that the point at which the change would need to be made - i.e. if someone is planning an upgrade from H to I they need to make sure they have the new config names in place before the update ?) Looking at the changes highlighted in nova.conf.sample it looks as if a lot more has changed - but I'm guessing this is an artifact of the way the file is generated rather that actual wholesale changes to config options. Either way I'm not sure anyone trying to plan around the upgrade impact should be expected to have to dig into the diff's of the changed files to work out what they need to do, and what time period they have to do it in. 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 ? Phil ________________________________________ From: Thierry Carrez [thie...@openstack.org] Sent: 07 January 2014 10:04 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] minimum review period for functional changes that break backwards compatibility Matt Riedemann wrote: > There is discussion in this thread about "wouldn't it be nice to have a > tag on commits for changes that impact upgrades?". There is. > > http://lists.openstack.org/pipermail/openstack-dev/2013-October/016619.html > > https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references > > Here is an example of a patch going through the gate now with > UpgradeImpact: > > https://review.openstack.org/#/c/62815/ The good thing about "UpgradeImpact" is that it's less subjective than "OpsImpact", and I think it catches what matters: backward-incompatible changes, upgrades needing manual intervention (or smart workarounds in packaging), etc. Additional benefit is that it's relevant for more than just the "ops" population: packagers and the release notes writers also need to track those. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
