Re: [openstack-dev] What's happening with stable release management?
On 08/09/2014 04:34 AM, Thierry Carrez wrote: > Thierry Carrez wrote: >> I'll upload a new tarball ASAP. I took down the wrong one. Sorry for the >> inconvenience... the issues here are not a policy problem, they are just >> human error in the original tag, complicated by CI staleness that made >> us think we fixed it while we didn't. > > keystone 2014.1.2.1 was just uploaded to fix that. I'm sorry for the > inconvenience this has caused. No worries Thierry, mistakes do happen. Though I've already upgraded oslo.config, oslo.messaging, and pycadf. I hope that's not an issue. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What's happening with stable release management?
Thierry Carrez wrote: > I'll upload a new tarball ASAP. I took down the wrong one. Sorry for the > inconvenience... the issues here are not a policy problem, they are just > human error in the original tag, complicated by CI staleness that made > us think we fixed it while we didn't. keystone 2014.1.2.1 was just uploaded to fix that. I'm sorry for the inconvenience this has caused. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What's happening with stable release management?
Thomas Goirand wrote: > Hi, > > For updating keystone from 2014.1.1 to 2014.1.2, I had to: > > - Upgrade oslo-config from 1.2.1 to 1.4.0.0~a3 > - Upgrade oslo.messaging from 1.3.0~a9 to 1.4.0.0~a3 > - Upgrade python-six from 1.6 to 1.7 > - Upgrade python-pycadf from 0.4 to 0.5.1 > - Add python-ldappool > - Add python-oslo.db > - Add python-oslo.i18n > - Add python-keystonemiddleware, which needs python-crypto >= 2.6 > (previously, 2.5 was enough) > > So, we have 5 major Python module upgrades, and 4 completely new > libraries which were not there in 2014.1.1. Some of the changes aren't > small at all. > > I'm sure that there's very valid reasons for each of the upgrades or > library addition, but I don't think that it is overall reasonable. If > this was to happen during the freeze of Debian, or worse, after a > release, upgrading all of this would be a nightmare, and I'm sure that > the Debian release team would simply refuse. > > Should I assign myself to program a robot which will vote -1 on all > change on the stable/Icehouse global-requirements.txt file? Or is sanity > still possible in OpenStack? :) > > It is my opinion that we need to review our release process for the > stable releases, policy for requirement changes, and need to adopt a way > more conservative attitude. No, actually this is because the 2014.1.2 tarball is still completely wrong. The tag is now OK, but due to some stale workspaces in our CI the tarball was still generated from the wrong (Juno) tag. I'll upload a new tarball ASAP. I took down the wrong one. Sorry for the inconvenience... the issues here are not a policy problem, they are just human error in the original tag, complicated by CI staleness that made us think we fixed it while we didn't. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] What's happening with stable release management?
Hi, For updating keystone from 2014.1.1 to 2014.1.2, I had to: - Upgrade oslo-config from 1.2.1 to 1.4.0.0~a3 - Upgrade oslo.messaging from 1.3.0~a9 to 1.4.0.0~a3 - Upgrade python-six from 1.6 to 1.7 - Upgrade python-pycadf from 0.4 to 0.5.1 - Add python-ldappool - Add python-oslo.db - Add python-oslo.i18n - Add python-keystonemiddleware, which needs python-crypto >= 2.6 (previously, 2.5 was enough) So, we have 5 major Python module upgrades, and 4 completely new libraries which were not there in 2014.1.1. Some of the changes aren't small at all. I'm sure that there's very valid reasons for each of the upgrades or library addition, but I don't think that it is overall reasonable. If this was to happen during the freeze of Debian, or worse, after a release, upgrading all of this would be a nightmare, and I'm sure that the Debian release team would simply refuse. Should I assign myself to program a robot which will vote -1 on all change on the stable/Icehouse global-requirements.txt file? Or is sanity still possible in OpenStack? :) It is my opinion that we need to review our release process for the stable releases, policy for requirement changes, and need to adopt a way more conservative attitude. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
