An issue was discovered with Keystone 2014.1.2 stable release tarball shortly after it was uploaded on the release page at: https://launchpad.net/keystone/icehouse/2014.1.2 A new tarball corresponding to 2014.1.2 code was generated and uploaded: md5sum: c8a85fc2ac76679eb1b674e0c2c65e36 keystone-2014.1.2.tar.gz sha1sum: c1d481d8b330e50da5ace19c23e5909c04fa1cba keystone-2014.1.2.tar.gz Please double-check that you got the right one. Regards chuck
Please double-check that you got the right one.
And if you fetched keystone.git repository earlier than 15:25 UTC today, you will need to remove the old tag and fetch new one with: git tag -d 2014.1.2; git fetch Correct tag is: object 6cbf835542d62e6e5db4b4aef7141b1731cad9dc type commit tag 2014.1.2 tagger Chuck Short <chuck.short@canonical.com> 1407511150 -0400 2014.1.2 gpg: Signature made Fri Aug 8 15:19:11 2014 UTC using DSA key ID FA14013B gpg: Good signature from "Chuck Short <chuck.short@canonical.com>"
Chuck Short wrote:
An issue was discovered with Keystone 2014.1.2 stable release tarball shortly after it was uploaded on the release page at: https://launchpad.net/keystone/icehouse/2014.1.2
A new tarball corresponding to 2014.1.2 code was generated and uploaded: md5sum: c8a85fc2ac76679eb1b674e0c2c65e36 keystone-2014.1.2.tar.gz sha1sum: c1d481d8b330e50da5ace19c23e5909c04fa1cba keystone-2014.1.2.tar.gz
Please double-check that you got the right one.
That tarball was actually still wrong. Our CI did not react correctly to us deleting and re-creating a tag, which resulted in the same faulty tarball to be reuploaded. I'm very sorry about that. A new tarball corresponding to 2014.1.2 code (tagged 2014.1.2.1) was generated and uploaded as keystone-2014.1.2.1.tar.gz: $ md5sum keystone-2014.1.2.1.tar.gz e29c1b8b1206c71ac86bc5b93e56f286 keystone-2014.1.2.1.tar.gz $ sha1sum keystone-2014.1.2.1.tar.gz c01ca8c2ed978bfbb30d5c1b946e16045094fc09 keystone-2014.1.2.1.tar.gz It was uploaded as a replacement tarball at: https://launchpad.net/keystone/icehouse/2014.1.2 Thanks you for your understanding. -- Thierry Carrez (ttx)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/08/14 17:57, Chuck Short wrote:
An issue was discovered with Keystone 2014.1.2 stable release tarball shortly after it was uploaded on the release page at: https://launchpad.net/keystone/icehouse/2014.1.2
A new tarball corresponding to 2014.1.2 code was generated and uploaded: md5sum: c8a85fc2ac76679eb1b674e0c2c65e36 keystone-2014.1.2.tar.gz sha1sum: c1d481d8b330e50da5ace19c23e5909c04fa1cba keystone-2014.1.2.tar.gz
Please double-check that you got the right one.
I wonder whether it's better to handle those kind of issues with releasing another minor release like 2014.1.2.1 for that specific package. Modifying tarballs in place sounds similar to e.g. amending git commit in place instead of fixing an issue in consequent patches. /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJT6Ia0AAoJEC5aWaUY1u57dHsIAIzF0vlYtF1G+lCDQFe6ROAJ KAK87BUplMFBQiBwwbhnOx74aQYCITdwW/jjBYi0iae/4pZpd5fY50awKGNPo2XV m2DWp20SDLgVbUlBq4PSRmbN4LIMjvjfhxm/3qfK4qJBunmqVYHIbAZ8DRNWX/nZ i4KkYa+i6MRvPUlp9iZTbjSL4q2EA010X0uo9dkmEbjFVguNqzKAgZxQ0b9V+GII 4vl7uu5OzEoCZuWYjcCIk9zOJgaFso9kGoZlFHe4CQC4389jyyfIJYnETSMtDvId Ni16n5d7w0TXsZKvpp5lTyvS6zrZwQATUAIQ6g2Gt/pjbIFKAA3W0asPMG++2V0= =2GZ+ -----END PGP SIGNATURE-----
Ihar Hrachyshka wrote:
On 08/08/14 17:57, Chuck Short wrote:
An issue was discovered with Keystone 2014.1.2 stable release tarball shortly after it was uploaded on the release page at: https://launchpad.net/keystone/icehouse/2014.1.2
A new tarball corresponding to 2014.1.2 code was generated and uploaded: md5sum: c8a85fc2ac76679eb1b674e0c2c65e36 keystone-2014.1.2.tar.gz sha1sum: c1d481d8b330e50da5ace19c23e5909c04fa1cba keystone-2014.1.2.tar.gz
Please double-check that you got the right one.
I wonder whether it's better to handle those kind of issues with releasing another minor release like 2014.1.2.1 for that specific package. Modifying tarballs in place sounds similar to e.g. amending git commit in place instead of fixing an issue in consequent patches.
I agree. Alan and I made a judgment call based on the number of downloads, the time the tarball was up, and the fact that only Keystone was affected... but I think we made the wrong choice. The delete/recreate tag created more pain, made us think we fixed it while we didn't, and screwed a number of git checkouts. Lesson learned: in such cases in the future, just tag a point point release (which is what we ended up doing to fix the mess anyway). Cheers, -- Thierry Carrez (ttx)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/08/14 11:31, Thierry Carrez wrote:
Ihar Hrachyshka wrote:
On 08/08/14 17:57, Chuck Short wrote:
An issue was discovered with Keystone 2014.1.2 stable release tarball shortly after it was uploaded on the release page at: https://launchpad.net/keystone/icehouse/2014.1.2
A new tarball corresponding to 2014.1.2 code was generated and uploaded: md5sum: c8a85fc2ac76679eb1b674e0c2c65e36 keystone-2014.1.2.tar.gz sha1sum: c1d481d8b330e50da5ace19c23e5909c04fa1cba keystone-2014.1.2.tar.gz
Please double-check that you got the right one.
I wonder whether it's better to handle those kind of issues with releasing another minor release like 2014.1.2.1 for that specific package. Modifying tarballs in place sounds similar to e.g. amending git commit in place instead of fixing an issue in consequent patches.
I agree. Alan and I made a judgment call based on the number of downloads, the time the tarball was up, and the fact that only Keystone was affected... but I think we made the wrong choice. The delete/recreate tag created more pain, made us think we fixed it while we didn't, and screwed a number of git checkouts.
Lesson learned: in such cases in the future, just tag a point point release (which is what we ended up doing to fix the mess anyway).
Thanks for info. Have we noted anywhere the fact that downstream should use 'unexpected' tag? I don't see anything at [1]. [1]: https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.2#OpenStack_Identity_.28... /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJT6JVOAAoJEC5aWaUY1u57fD0H/RUOs6gICAqHbGOO+h/OTc5N AJ+maQn7ekCLTLD1qXSJ6GLl1gJIWViUIIg/k3/WVakgsGg4KZr8GlSWSzZVnO9m 3pjogaOzFkIj9YlCqjPQCP1JA0JuxkyPc6YvgSau/99s1oxQhqymc8yzClh316W3 FTcU5ub0o1W/DkeGG/fGafYn0j5Pp7MRsc+bhsOJtcFiStgLP5hIf9YD1GPuzMo5 /neSrIgyeduf705RVnVb4P9WkI5HwufuDxao0lqRQlgsolk6ljKiYwzIH8ol7RVD 4RPdEm4eGcFUamYjLszwHNfNgKHzP22FetAZDZZG5v94AcdwoZxfXuHOQti2K0M= =MhsR -----END PGP SIGNATURE-----
Ihar Hrachyshka wrote:
Lesson learned: in such cases in the future, just tag a point point release (which is what we ended up doing to fix the mess anyway).
Thanks for info. Have we noted anywhere the fact that downstream should use 'unexpected' tag? I don't see anything at [1].
[1]: https://wiki.openstack.org/wiki/ReleaseNotes/2014.1.2#OpenStack_Identity_.28...
That's a good point, I added a quick Note to the release notes. -- Thierry Carrez (ttx)
participants (4)
-
Alan Pevec
-
Chuck Short
-
Ihar Hrachyshka
-
Thierry Carrez