)]}'
{"specs/backwards-compat-libs-clients.rst":[{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"14e18a173995dc1a9e224b6e2e8409f8408ca1d5","unresolved":false,"context_lines":[{"line_number":1,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":2,"context_line":"backwards compatibility for clients and libraries"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_f22205b9","line":2,"updated":"2015-09-25 12:48:32.000000000","message":"Capital B since it\u0027s used as a title in specs publication.","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"14e18a173995dc1a9e224b6e2e8409f8408ca1d5","unresolved":false,"context_lines":[{"line_number":5,"context_line":"Problem description"},{"line_number":6,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"Both our Python client libraries and our olso libraries cause difficulty for"},{"line_number":9,"context_line":"redistributors when we have backwards incompatible releases occur. As our"},{"line_number":10,"context_line":"servers become more and more disaggregated in their release schedules, ensuring"},{"line_number":11,"context_line":"compatibility with all supported servers becomes substantially more important"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_b2032d0f","line":8,"updated":"2015-09-25 12:48:32.000000000","message":"oslo","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"14e18a173995dc1a9e224b6e2e8409f8408ca1d5","unresolved":false,"context_lines":[{"line_number":26,"context_line":"  We\u0027ll test this through devstack cross-release tests."},{"line_number":27,"context_line":"* Stop branching these things at each coordinated release."},{"line_number":28,"context_line":"* Keep master always releasable (we already aim at this)."},{"line_number":29,"context_line":"* Use semver to signal compatibilty breaks (these are expected just not ones"},{"line_number":30,"context_line":"  that affect supported releases). For instance, we might deprecate something"},{"line_number":31,"context_line":"  in Mitaka, and then in P garbage collect the deprecated thing, which is"},{"line_number":32,"context_line":"  an API break and will require a major version increment."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_554ddb70","line":29,"updated":"2015-09-25 12:48:32.000000000","message":"compatibility","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"14e18a173995dc1a9e224b6e2e8409f8408ca1d5","unresolved":false,"context_lines":[{"line_number":29,"context_line":"* Use semver to signal compatibilty breaks (these are expected just not ones"},{"line_number":30,"context_line":"  that affect supported releases). For instance, we might deprecate something"},{"line_number":31,"context_line":"  in Mitaka, and then in P garbage collect the deprecated thing, which is"},{"line_number":32,"context_line":"  an API break and will require a major version increment."},{"line_number":33,"context_line":"* Commit to, and test, co-installability of each library back to the oldest"},{"line_number":34,"context_line":"  supported OpenStack branch."},{"line_number":35,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_f5c18f81","line":32,"updated":"2015-09-25 12:48:32.000000000","message":"One issue is that the \"supported releases\" is a bit of an unknown quantity, since the stable team decides when to stop \"supporting\" a given release.\n\nAlso, in the current setup, \"supported\" meant pushing fixes and testing in CI. \"Not being supported\" didn\u0027t mean we\u0027d actively break it by garbage-collecting deprecated changes. Unsupported releases still worked. If unsupported now means \"broken\" we\u0027ll likely have to support a lot more than 2 releases.","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"26b906eb18a18416670b66e231291d750263c541","unresolved":false,"context_lines":[{"line_number":29,"context_line":"* Use semver to signal compatibilty breaks (these are expected just not ones"},{"line_number":30,"context_line":"  that affect supported releases). For instance, we might deprecate something"},{"line_number":31,"context_line":"  in Mitaka, and then in P garbage collect the deprecated thing, which is"},{"line_number":32,"context_line":"  an API break and will require a major version increment."},{"line_number":33,"context_line":"* Commit to, and test, co-installability of each library back to the oldest"},{"line_number":34,"context_line":"  supported OpenStack branch."},{"line_number":35,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_b5fb92c0","line":32,"in_reply_to":"9a1a9d01_f5c18f81","updated":"2015-09-29 19:19:13.000000000","message":"I don\u0027t believe this spec alters the rate of bit-rot of gc\u0027d branches of code. I\u0027ll call that out explicitly in my next revision.","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"14e18a173995dc1a9e224b6e2e8409f8408ca1d5","unresolved":false,"context_lines":[{"line_number":122,"context_line":"Branches have the following benefits."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"1. Distros can store the backported patches they ship in the OpenStack"},{"line_number":125,"context_line":"   branches."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Requirements management"},{"line_number":128,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_15b443f0","line":125,"updated":"2015-09-25 12:48:32.000000000","message":"+ distros don\u0027t have to maintain their own stable branches for libraries.\n\nDistros have strong constraints on what updates they can deliver on a given distro version, so they have to maintain stable branches for the libraries they ship anyway. Having the branch maintained upstream considerably simplifies their work. For example they get security patches for free from upstream rather than have to craft their own backport.","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"26b906eb18a18416670b66e231291d750263c541","unresolved":false,"context_lines":[{"line_number":122,"context_line":"Branches have the following benefits."},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"1. Distros can store the backported patches they ship in the OpenStack"},{"line_number":125,"context_line":"   branches."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Requirements management"},{"line_number":128,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_f5fb4a79","line":125,"in_reply_to":"9a1a9d01_15b443f0","updated":"2015-09-29 19:19:13.000000000","message":"Distros have a lot of latitude actually - all distros I know of have mechanisms for dealing with Firefox and Chromium, two examples of very complex software, with nasty dependency chains, where there is no concept of \u0027old but supported\u0027. Whether distros will *want* to put the OpenStack dependencies into that mechanism is an open  question I hope to get input on from this spec.\n\nHowever, distros *do* maintain their own stable branches: every distro I know of ships ahead of the OpenStack stable branch content: they collaborate on patches with OpenStack, but they don\u0027t depend on the stable branches to deliver their content. So I  don\u0027t agree that \u0027don\u0027t have to maintain their own stable branches\u0027 is actually a benefit. If their behaviour was different, then it would be :)","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"14e18a173995dc1a9e224b6e2e8409f8408ca1d5","unresolved":false,"context_lines":[{"line_number":254,"context_line":"deprecated paths. However, this doesn\u0027t provide an answer to the version"},{"line_number":255,"context_line":"numbering headache - semver is not a time based branching scheme - we\u0027d need"},{"line_number":256,"context_line":"to design and implement some new scheme within the parameters of PEP 440 to"},{"line_number":257,"context_line":"cater for that."},{"line_number":258,"context_line":""},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_f5ff4f32","line":257,"updated":"2015-09-25 12:48:32.000000000","message":"Could you expand on that version numbering headache ? Currently we operate stable branches with a x.y.z semver numbering with no headache, simply by restricting stable branch updates to .z bumps and requiring a .y bump on series boundaries. If we kept branches we could continue to operate with the same headache-free rules ?","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"26b906eb18a18416670b66e231291d750263c541","unresolved":false,"context_lines":[{"line_number":254,"context_line":"deprecated paths. However, this doesn\u0027t provide an answer to the version"},{"line_number":255,"context_line":"numbering headache - semver is not a time based branching scheme - we\u0027d need"},{"line_number":256,"context_line":"to design and implement some new scheme within the parameters of PEP 440 to"},{"line_number":257,"context_line":"cater for that."},{"line_number":258,"context_line":""},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9a1a9d01_f59caa0f","line":257,"in_reply_to":"9a1a9d01_f5ff4f32","updated":"2015-09-29 19:19:13.000000000","message":"Done","commit_id":"c2428c6f0700ac0d4223b25935d1a5e71a33ab1d"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"cbed002dafa56d38d44da3d49c10d39af026c374","unresolved":false,"context_lines":[{"line_number":270,"context_line":"backport. We currently are treating all requirements changes as feature"},{"line_number":271,"context_line":"changes - changing the minor version - which means all requirements changes to"},{"line_number":272,"context_line":"non-master branches will collide with the master version namespace until"},{"line_number":273,"context_line":"master has done as many minor releases."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Implementation"},{"line_number":276,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9a1a9d01_b874e767","line":273,"updated":"2015-09-29 19:31:00.000000000","message":"We allow requirements updates in patch releases from stable branches if those requirements updates are related to bugs in some way.","commit_id":"8b63326d018adf464a3d0261561cf6bf742705cb"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"a53683b3e2d902ef154edc8dc10d4523143bab5d","unresolved":false,"context_lines":[{"line_number":270,"context_line":"backport. We currently are treating all requirements changes as feature"},{"line_number":271,"context_line":"changes - changing the minor version - which means all requirements changes to"},{"line_number":272,"context_line":"non-master branches will collide with the master version namespace until"},{"line_number":273,"context_line":"master has done as many minor releases."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Implementation"},{"line_number":276,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba8a016a_d5219ffc","line":273,"in_reply_to":"9a1a9d01_b874e767","updated":"2015-11-18 00:37:18.000000000","message":"Yes, but thats not actually my point - my point is that when on master we change requirements and then release x.y.z, if the old version was 1.2.3, the new version is 1.3.0 even if only requirements changed. We can\u0027t do that on stable branches because 1.2.4 etc are the only permitted numbers.","commit_id":"8b63326d018adf464a3d0261561cf6bf742705cb"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"17fb8fcc4c0eedfd1163306093cce6e514195de3","unresolved":false,"context_lines":[{"line_number":10,"context_line":"servers become more and more disaggregated in their release schedules, ensuring"},{"line_number":11,"context_line":"compatibility with all supported servers becomes substantially more important"},{"line_number":12,"context_line":"to make sure that what we\u0027re producing can actually be installed and used"},{"line_number":13,"context_line":"reasonably."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Proposed change"},{"line_number":16,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_05dbc2ee","line":13,"updated":"2015-12-01 03:14:56.000000000","message":"Just to be clear: this is not so much about API compatibility but about compatibility dictated by the package versions we use for the requirements that client and server components rely on? Sorry for my naive question.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":10,"context_line":"servers become more and more disaggregated in their release schedules, ensuring"},{"line_number":11,"context_line":"compatibility with all supported servers becomes substantially more important"},{"line_number":12,"context_line":"to make sure that what we\u0027re producing can actually be installed and used"},{"line_number":13,"context_line":"reasonably."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Proposed change"},{"line_number":16,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_383b49d3","line":13,"in_reply_to":"9a8ffd7b_05dbc2ee","updated":"2015-12-02 00:22:00.000000000","message":"yes. Added some prose to disambiguate","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0be85a9b974d925f9fef2056d2794b054db4906a","unresolved":false,"context_lines":[{"line_number":10,"context_line":"servers become more and more disaggregated in their release schedules, ensuring"},{"line_number":11,"context_line":"compatibility with all supported servers becomes substantially more important"},{"line_number":12,"context_line":"to make sure that what we\u0027re producing can actually be installed and used"},{"line_number":13,"context_line":"reasonably."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Proposed change"},{"line_number":16,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_ece0a698","line":13,"in_reply_to":"9a8ffd7b_383b49d3","updated":"2015-12-02 00:37:44.000000000","message":"thanks","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6159,"name":"Flavio Percoco Premoli","display_name":"flaper87","email":"flavio.percoco@flyrlabs.com","username":"flaper87"},"change_message_id":"0861fbb5177695813465cb57eecc1fcd477147aa","unresolved":false,"context_lines":[{"line_number":27,"context_line":"* Keep master always releasable (we already aim at this)."},{"line_number":28,"context_line":"* Use semver to signal compatibility breaks (these are expected just not ones"},{"line_number":29,"context_line":"  that affect supported releases). For instance, we might deprecate something"},{"line_number":30,"context_line":"  in Mitaka, and then in P garbage collect the deprecated thing, which is"},{"line_number":31,"context_line":"  an API break and will require a major version increment. The point at which"},{"line_number":32,"context_line":"  we can garbage collect deprecated things will be determined by the period"},{"line_number":33,"context_line":"  that the stable maintenance team decide to maintain each stable branch for."}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_9fa8e4dc","line":30,"updated":"2015-11-26 17:53:06.000000000","message":"nit: lol @ garbage collect. Perhaps \"remove\"?","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4c3efb7398fc226c2e4b096a1c6f28d13809b63d","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  in Mitaka, and then in P garbage collect the deprecated thing, which is"},{"line_number":31,"context_line":"  an API break and will require a major version increment. The point at which"},{"line_number":32,"context_line":"  we can garbage collect deprecated things will be determined by the period"},{"line_number":33,"context_line":"  that the stable maintenance team decide to maintain each stable branch for."},{"line_number":34,"context_line":"  Branches that are no longer maintained will have a known-good set of"},{"line_number":35,"context_line":"  dependency versions from the point at which maintenance and support stopped,"},{"line_number":36,"context_line":"  which will remain valid indefinitely."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_f0471149","line":33,"updated":"2015-11-18 00:52:34.000000000","message":"I think it also is up to the PTL(s) imho, not just \u0027stable maintenance team\u0027 because it sorta feels like that\u0027s the whole point of semver, to make it possible to do major version changes and not have to wait 1.5 years (3 cycles) for that to happen...\n\nIf PTL(s) are supporting older branches, for example put 1.x on a branch, support it, and move forward with 2.x and its potentially breaking changes,\n\nObviously we don\u0027t need to follow firefox and chrome (and others) here and release new major versions every week, but u get the point...","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"3b75ae98c39f7b5b6d4cedf9428ef03ed50a4bea","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  in Mitaka, and then in P garbage collect the deprecated thing, which is"},{"line_number":31,"context_line":"  an API break and will require a major version increment. The point at which"},{"line_number":32,"context_line":"  we can garbage collect deprecated things will be determined by the period"},{"line_number":33,"context_line":"  that the stable maintenance team decide to maintain each stable branch for."},{"line_number":34,"context_line":"  Branches that are no longer maintained will have a known-good set of"},{"line_number":35,"context_line":"  dependency versions from the point at which maintenance and support stopped,"},{"line_number":36,"context_line":"  which will remain valid indefinitely."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_68a8d58d","line":33,"in_reply_to":"ba8a016a_a6b35b99","updated":"2015-11-19 07:29:44.000000000","message":"So I think compat breaks when we gc things are going to be common - but we can schedule them - e.g. first quarter of each cycle. The main thing is to make the compat break be non-disruptive: eg be confident we\u0027re not affecting users, and we\u0027ve only really got three means for that:\n\n1 never do it\n\n2 assume that our published support windows will be followed - which is what this spec does\n\n3 instrument our libraries to report back on whats used. Aieee.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"e7a3dd26c22d91630e7955a5022ce9cba9aa592a","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  in Mitaka, and then in P garbage collect the deprecated thing, which is"},{"line_number":31,"context_line":"  an API break and will require a major version increment. The point at which"},{"line_number":32,"context_line":"  we can garbage collect deprecated things will be determined by the period"},{"line_number":33,"context_line":"  that the stable maintenance team decide to maintain each stable branch for."},{"line_number":34,"context_line":"  Branches that are no longer maintained will have a known-good set of"},{"line_number":35,"context_line":"  dependency versions from the point at which maintenance and support stopped,"},{"line_number":36,"context_line":"  which will remain valid indefinitely."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_a6b35b99","line":33,"in_reply_to":"ba8a016a_f0471149","updated":"2015-11-18 23:21:49.000000000","message":"Ok I think I more understand this now, although it would be nice to think of the situation where a major bump needs to happen (for some reason) and think about how we can resolve this (hopefully out of the ordinary) event/occurrence.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4c3efb7398fc226c2e4b096a1c6f28d13809b63d","unresolved":false,"context_lines":[{"line_number":35,"context_line":"  dependency versions from the point at which maintenance and support stopped,"},{"line_number":36,"context_line":"  which will remain valid indefinitely."},{"line_number":37,"context_line":"* Commit to, and test, co-installability of each library back to the oldest"},{"line_number":38,"context_line":"  supported OpenStack branch."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"There is ongoing perceived value in having ultra-stable branches where no new"},{"line_number":41,"context_line":"features are present; this spec retains our stable branches... stopping stable"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_707241af","line":38,"updated":"2015-11-18 00:52:34.000000000","message":"Cool, this really helps if a dep. solver is in PIP I think...","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"3b75ae98c39f7b5b6d4cedf9428ef03ed50a4bea","unresolved":false,"context_lines":[{"line_number":35,"context_line":"  dependency versions from the point at which maintenance and support stopped,"},{"line_number":36,"context_line":"  which will remain valid indefinitely."},{"line_number":37,"context_line":"* Commit to, and test, co-installability of each library back to the oldest"},{"line_number":38,"context_line":"  supported OpenStack branch."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"There is ongoing perceived value in having ultra-stable branches where no new"},{"line_number":41,"context_line":"features are present; this spec retains our stable branches... stopping stable"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_488ab11c","line":38,"in_reply_to":"ba8a016a_707241af","updated":"2015-11-19 07:29:44.000000000","message":"We can - and this spec describes how - do a lot without a solver. One is coming, but one step at a time :0","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"17fb8fcc4c0eedfd1163306093cce6e514195de3","unresolved":false,"context_lines":[{"line_number":41,"context_line":"features are present; this spec retains our stable branches... stopping stable"},{"line_number":42,"context_line":"branches would require two key things - that we don\u0027t have API breaks on"},{"line_number":43,"context_line":"master, and that new features introduced do not cause instabilities, and we"},{"line_number":44,"context_line":"have no plan for preventing such instabilities."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"status quo details"},{"line_number":47,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_a58c3636","line":44,"updated":"2015-12-01 03:14:56.000000000","message":"Not sure I fully understand what this paragraph is supposed to say, could you rephrase?","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":41,"context_line":"features are present; this spec retains our stable branches... stopping stable"},{"line_number":42,"context_line":"branches would require two key things - that we don\u0027t have API breaks on"},{"line_number":43,"context_line":"master, and that new features introduced do not cause instabilities, and we"},{"line_number":44,"context_line":"have no plan for preventing such instabilities."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"status quo details"},{"line_number":47,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_f89f015d","line":44,"in_reply_to":"9a8ffd7b_a58c3636","updated":"2015-12-02 00:22:00.000000000","message":"it describes retaining stable branches of libraries.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0be85a9b974d925f9fef2056d2794b054db4906a","unresolved":false,"context_lines":[{"line_number":41,"context_line":"features are present; this spec retains our stable branches... stopping stable"},{"line_number":42,"context_line":"branches would require two key things - that we don\u0027t have API breaks on"},{"line_number":43,"context_line":"master, and that new features introduced do not cause instabilities, and we"},{"line_number":44,"context_line":"have no plan for preventing such instabilities."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"status quo details"},{"line_number":47,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_ecf74657","line":44,"in_reply_to":"9a8ffd7b_f89f015d","updated":"2015-12-02 00:37:44.000000000","message":"gotcha","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},"change_message_id":"7d2ffd492b403fdef4c83ea460b7bc1892c5dfd8","unresolved":false,"context_lines":[{"line_number":47,"context_line":"------------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"We broadly commit to backwards compatibility, but often detect issues"},{"line_number":50,"context_line":"post-release. As we integration-test all changes, we can\u0027t make actually do"},{"line_number":51,"context_line":"backwards incompatible changes in a single step today anyway. What actually"},{"line_number":52,"context_line":"happens is that we do an expand-contract process within master, but the"},{"line_number":53,"context_line":"contraction is done too early, breaking older branches."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_b502db07","line":50,"updated":"2015-11-23 21:58:46.000000000","message":"\"make actually do\" -\u003e \"make\" or \"actually do\" (suspecting \"make\" due to use of \"actually\" on line 51)","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":47,"context_line":"------------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"We broadly commit to backwards compatibility, but often detect issues"},{"line_number":50,"context_line":"post-release. As we integration-test all changes, we can\u0027t make actually do"},{"line_number":51,"context_line":"backwards incompatible changes in a single step today anyway. What actually"},{"line_number":52,"context_line":"happens is that we do an expand-contract process within master, but the"},{"line_number":53,"context_line":"contraction is done too early, breaking older branches."}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_b88f3922","line":50,"in_reply_to":"ba8a016a_b502db07","updated":"2015-12-02 00:22:00.000000000","message":"thanks","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"f97a841ddab05c47c78fc274f8157bbf0f9c151b","unresolved":false,"context_lines":[{"line_number":58,"context_line":"The lack of strong consistent backwards compatibility shows up as a number of"},{"line_number":59,"context_line":"individual issues:"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"1. Upper caps in stable branches lead to regular repeated deadlocks and gate"},{"line_number":62,"context_line":"   failures. The work we\u0027ve done with constraints mitigates this, but we still"},{"line_number":63,"context_line":"   can\u0027t use upper caps except where we can guarantee that we will be able to"},{"line_number":64,"context_line":"   preserve overlapping regions across all upgrades. The lack of a reliable"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_fe3de4bb","line":61,"updated":"2015-12-01 07:28:27.000000000","message":"yes, let\u0027s not use that again","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},"change_message_id":"7d2ffd492b403fdef4c83ea460b7bc1892c5dfd8","unresolved":false,"context_lines":[{"line_number":68,"context_line":"2. Updating distributions like Fedora and Debian is not an atomic operation:"},{"line_number":69,"context_line":"   all the components of OpenStack need to be upgraded serially, and during"},{"line_number":70,"context_line":"   that transition all components need to be both co-installable and mutually"},{"line_number":71,"context_line":"   compatible. Not that distributions that package each release only need"},{"line_number":72,"context_line":"   release-to-release compatibility. Distributions that skip releases, or who"},{"line_number":73,"context_line":"   release furthr apart than our 6-monthly cycle, need wider compatibility"},{"line_number":74,"context_line":"   periods to avoid this friction."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_90dd6516","line":71,"updated":"2015-11-23 21:58:46.000000000","message":"\"Not that\" or \"Note that\"?","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"e7a3dd26c22d91630e7955a5022ce9cba9aa592a","unresolved":false,"context_lines":[{"line_number":70,"context_line":"   that transition all components need to be both co-installable and mutually"},{"line_number":71,"context_line":"   compatible. Not that distributions that package each release only need"},{"line_number":72,"context_line":"   release-to-release compatibility. Distributions that skip releases, or who"},{"line_number":73,"context_line":"   release furthr apart than our 6-monthly cycle, need wider compatibility"},{"line_number":74,"context_line":"   periods to avoid this friction."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"3. A common scenario is having to upgrade clients to talk to newer clouds, but"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_c6469f7a","line":73,"updated":"2015-11-18 23:21:49.000000000","message":"furthr  -\u003e further","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4c3efb7398fc226c2e4b096a1c6f28d13809b63d","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   compatible. Not that distributions that package each release only need"},{"line_number":72,"context_line":"   release-to-release compatibility. Distributions that skip releases, or who"},{"line_number":73,"context_line":"   release furthr apart than our 6-monthly cycle, need wider compatibility"},{"line_number":74,"context_line":"   periods to avoid this friction."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"3. A common scenario is having to upgrade clients to talk to newer clouds, but"},{"line_number":77,"context_line":"   not wanting to break any other software on the machine. With distributions"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_b09f49b3","line":74,"updated":"2015-11-18 00:52:34.000000000","message":"I get why this is here, but meh, this almost starts to feel like a distro problem, not upstreams...","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"e077f97fd8adde8a1d791f391508ebc171ae1579","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   compatible. Not that distributions that package each release only need"},{"line_number":72,"context_line":"   release-to-release compatibility. Distributions that skip releases, or who"},{"line_number":73,"context_line":"   release furthr apart than our 6-monthly cycle, need wider compatibility"},{"line_number":74,"context_line":"   periods to avoid this friction."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"3. A common scenario is having to upgrade clients to talk to newer clouds, but"},{"line_number":77,"context_line":"   not wanting to break any other software on the machine. With distributions"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_5966e52a","line":74,"in_reply_to":"ba8a016a_88d97924","updated":"2015-11-19 16:05:21.000000000","message":"Agreed.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"3b75ae98c39f7b5b6d4cedf9428ef03ed50a4bea","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   compatible. Not that distributions that package each release only need"},{"line_number":72,"context_line":"   release-to-release compatibility. Distributions that skip releases, or who"},{"line_number":73,"context_line":"   release furthr apart than our 6-monthly cycle, need wider compatibility"},{"line_number":74,"context_line":"   periods to avoid this friction."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"3. A common scenario is having to upgrade clients to talk to newer clouds, but"},{"line_number":77,"context_line":"   not wanting to break any other software on the machine. With distributions"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_88d97924","line":74,"in_reply_to":"ba8a016a_b09f49b3","updated":"2015-11-19 07:29:44.000000000","message":"Well, to a degree yes, but Python itself places a lot of this constraint on us, because of its module model. Even using venvs doesn\u0027t eliminate it entirely, because e.g. all the users of oslo.config are potentially upgrading their use of APIs at different times - coinstallability mitigation through containers etc only shift the problem around, it doesn\u0027t eliminate it.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3778837507ba65bf9e7c5f41cc7ca78140ee2dc0","unresolved":false,"context_lines":[{"line_number":85,"context_line":"4. A lack of clear backwards compatibility makes encouraging new users tricky"},{"line_number":86,"context_line":"   at best: folk don\u0027t want to be facing broken builds (ever). For instance,"},{"line_number":87,"context_line":"   keystoneauth explicitly avoids oslo libraries to ensure it won\u0027t cause"},{"line_number":88,"context_line":"   dependency headaches for its users."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Not being rigorous about backwards compatibility may permit us to move faster"},{"line_number":91,"context_line":"in some regards, but because we always have to do an expand-contract pattern,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_49a460b8","line":88,"updated":"2015-12-01 15:45:34.000000000","message":"I don\u0027t think keystoneauth is avoiding oslo libraries to avoid dependency issues. It\u0027s avoiding all libraries except for necessary ones to keep the install as easy as possible. I don\u0027t think the example is correct and should be switched to something else.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4c3efb7398fc226c2e4b096a1c6f28d13809b63d","unresolved":false,"context_lines":[{"line_number":85,"context_line":"4. A lack of clear backwards compatibility makes encouraging new users tricky"},{"line_number":86,"context_line":"   at best: folk don\u0027t want to be facing broken builds (ever). For instance,"},{"line_number":87,"context_line":"   keystoneauth explicitly avoids oslo libraries to ensure it won\u0027t cause"},{"line_number":88,"context_line":"   dependency headaches for its users."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Not being rigorous about backwards compatibility may permit us to move faster"},{"line_number":91,"context_line":"in some regards, but because we always have to do an expand-contract pattern,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_30acb9ec","line":88,"updated":"2015-11-18 00:52:34.000000000","message":"This seems like a chat that needs to happen with the keystoneautho people, sticking ones head into the ground isn\u0027t a good way to go about life... Avoidance doesn\u0027t exactly seem like the good solution to any problems in software (especially the human side of the issue doesn\u0027t get any better when stuff like this happens/is learned about).","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":85,"context_line":"4. A lack of clear backwards compatibility makes encouraging new users tricky"},{"line_number":86,"context_line":"   at best: folk don\u0027t want to be facing broken builds (ever). For instance,"},{"line_number":87,"context_line":"   keystoneauth explicitly avoids oslo libraries to ensure it won\u0027t cause"},{"line_number":88,"context_line":"   dependency headaches for its users."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Not being rigorous about backwards compatibility may permit us to move faster"},{"line_number":91,"context_line":"in some regards, but because we always have to do an expand-contract pattern,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_3d033b44","line":88,"in_reply_to":"9a8ffd7b_49a460b8","updated":"2015-12-02 00:22:00.000000000","message":"I don\u0027t understand the \u0027install as easy as possible\u0027 thing - pip install is *very easy* even with many dependencies... but many dependencies do have problems: a) they may conflict, b) they have binary dependencies or c) they are fragile.\n\nBackwards compat drives c), pinning (which we\u0027ve addressed) drives a), leaving b) which is obviously a per-library thing.\n\nWhen this was discussed on IRC a few months back, it was my understanding that keystone was actively avoiding using libraries - making development harder - because of concerns from a/b/c above: and that oslo was considered to be having issues within the a/c categories. If I\u0027m wrong about that - great.\n\nRight now things like https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/conf.py#L30 which will error if oslo.config isn\u0027t installed seem weird to me, and I guess I really don\u0027t understand what ksa is trying to achieve.\n\nI\u0027ll remove the example anyhow, but if you could help me understand I\u0027d love that.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"3b75ae98c39f7b5b6d4cedf9428ef03ed50a4bea","unresolved":false,"context_lines":[{"line_number":85,"context_line":"4. A lack of clear backwards compatibility makes encouraging new users tricky"},{"line_number":86,"context_line":"   at best: folk don\u0027t want to be facing broken builds (ever). For instance,"},{"line_number":87,"context_line":"   keystoneauth explicitly avoids oslo libraries to ensure it won\u0027t cause"},{"line_number":88,"context_line":"   dependency headaches for its users."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Not being rigorous about backwards compatibility may permit us to move faster"},{"line_number":91,"context_line":"in some regards, but because we always have to do an expand-contract pattern,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_68321561","line":88,"in_reply_to":"ba8a016a_30acb9ec","updated":"2015-11-19 07:29:44.000000000","message":"They are avoiding a real repeated problem we caused. As an exemplar for the argument for backwards compat, its perfect :). Even if we convince them to do something different, that conversation and that pain will have to be repeated again and again - or we change the thing that is provoking the situation.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"e077f97fd8adde8a1d791f391508ebc171ae1579","unresolved":false,"context_lines":[{"line_number":85,"context_line":"4. A lack of clear backwards compatibility makes encouraging new users tricky"},{"line_number":86,"context_line":"   at best: folk don\u0027t want to be facing broken builds (ever). For instance,"},{"line_number":87,"context_line":"   keystoneauth explicitly avoids oslo libraries to ensure it won\u0027t cause"},{"line_number":88,"context_line":"   dependency headaches for its users."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Not being rigorous about backwards compatibility may permit us to move faster"},{"line_number":91,"context_line":"in some regards, but because we always have to do an expand-contract pattern,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_d97ad5bc","line":88,"in_reply_to":"ba8a016a_68321561","updated":"2015-11-19 16:05:21.000000000","message":"We all need to have a group hug, haha.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"f97a841ddab05c47c78fc274f8157bbf0f9c151b","unresolved":false,"context_lines":[{"line_number":85,"context_line":"4. A lack of clear backwards compatibility makes encouraging new users tricky"},{"line_number":86,"context_line":"   at best: folk don\u0027t want to be facing broken builds (ever). For instance,"},{"line_number":87,"context_line":"   keystoneauth explicitly avoids oslo libraries to ensure it won\u0027t cause"},{"line_number":88,"context_line":"   dependency headaches for its users."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Not being rigorous about backwards compatibility may permit us to move faster"},{"line_number":91,"context_line":"in some regards, but because we always have to do an expand-contract pattern,"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_23d039c9","line":88,"in_reply_to":"ba8a016a_d97ad5bc","updated":"2015-12-01 07:28:27.000000000","message":"we also wanted to make it as light as possible: https://github.com/openstack/keystoneauth/blob/master/requirements.txt","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"e7a3dd26c22d91630e7955a5022ce9cba9aa592a","unresolved":false,"context_lines":[{"line_number":119,"context_line":"   point 1."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"4. Distributions can only have one version of each component installed at a"},{"line_number":122,"context_line":"   time. The way large branched things are typically installed is to install a"},{"line_number":123,"context_line":"   branch version in the package name. E.g. \u0027python3.4 version 3.4\u0027 rather"},{"line_number":124,"context_line":"   than \u0027python version 3.4\u0027. This has a pretty high cost, and as a"},{"line_number":125,"context_line":"   prerequisite either demands that the things be co-installable, or that they"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_f92ca49a","line":122,"updated":"2015-11-18 23:21:49.000000000","message":"I think this might be different if we have an actual openstack deployment reference architecture, because really certain API servers shouldn\u0027t be running on the same box IMHO... and if the deployment reference architecture has separated boxes for different components then they need not all have to install all using the same packages (co-installable packages) of the same versions...","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"f97a841ddab05c47c78fc274f8157bbf0f9c151b","unresolved":false,"context_lines":[{"line_number":121,"context_line":"4. Distributions can only have one version of each component installed at a"},{"line_number":122,"context_line":"   time. The way large branched things are typically installed is to install a"},{"line_number":123,"context_line":"   branch version in the package name. E.g. \u0027python3.4 version 3.4\u0027 rather"},{"line_number":124,"context_line":"   than \u0027python version 3.4\u0027. This has a pretty high cost, and as a"},{"line_number":125,"context_line":"   prerequisite either demands that the things be co-installable, or that they"},{"line_number":126,"context_line":"   conflict with each other. This is precisely the same set of issues that"},{"line_number":127,"context_line":"   having backwards incompatibilities provokes."}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_5e73d0b4","line":124,"updated":"2015-12-01 07:28:27.000000000","message":"see also: keystoneauth1 version 1.1.0","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3778837507ba65bf9e7c5f41cc7ca78140ee2dc0","unresolved":false,"context_lines":[{"line_number":124,"context_line":"   than \u0027python version 3.4\u0027. This has a pretty high cost, and as a"},{"line_number":125,"context_line":"   prerequisite either demands that the things be co-installable, or that they"},{"line_number":126,"context_line":"   conflict with each other. This is precisely the same set of issues that"},{"line_number":127,"context_line":"   having backwards incompatibilities provokes."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Stable branches have the following benefits."},{"line_number":130,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_89ed68b9","line":127,"updated":"2015-12-01 15:45:34.000000000","message":"distributions could do virtualenvs just like other deployers do if they wanted to.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":124,"context_line":"   than \u0027python version 3.4\u0027. This has a pretty high cost, and as a"},{"line_number":125,"context_line":"   prerequisite either demands that the things be co-installable, or that they"},{"line_number":126,"context_line":"   conflict with each other. This is precisely the same set of issues that"},{"line_number":127,"context_line":"   having backwards incompatibilities provokes."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Stable branches have the following benefits."},{"line_number":130,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_bdbc0b6d","line":127,"in_reply_to":"9a8ffd7b_89ed68b9","updated":"2015-12-02 00:22:00.000000000","message":"If they do, we can revisit our discussion here; but it seems important to me that we accept what other folk are doing as an input to this, rather than trying to boil the ocean changing how Debian and Ubuntu and RHEL and Fedora and Suse and likely many others operate. nix and gentoo are kindof special case - and I don\u0027t know how deep their multiple-version-capabilities go.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"581b96609e09216a0012b2100634b400b37f69eb","unresolved":false,"context_lines":[{"line_number":129,"context_line":"Stable branches have the following benefits."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"1. (Linux and OpenStack) distributors can store the backported patches they"},{"line_number":132,"context_line":"   ship in the OpenStack branches."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"2. Conservative deployments can choose to track completely stable versions (as"},{"line_number":135,"context_line":"   long as they don\u0027t run into the issues with versions and single"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_30bdc168","line":132,"updated":"2015-11-25 13:01:18.000000000","message":"I like to frame the benefit as every downstream being able to collaborate on a common set of backports, reducing useless duplication of work (which is what OpenStack is all about after all). There are also some edge interoperability benefit in converging on a common set of backports. It also facilitates the work on the vulnerability team to have a base to produce patches for.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":129,"context_line":"Stable branches have the following benefits."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"1. (Linux and OpenStack) distributors can store the backported patches they"},{"line_number":132,"context_line":"   ship in the OpenStack branches."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"2. Conservative deployments can choose to track completely stable versions (as"},{"line_number":135,"context_line":"   long as they don\u0027t run into the issues with versions and single"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_2c36aee7","line":132,"in_reply_to":"9a8ffd7b_30bdc168","updated":"2015-12-02 00:22:00.000000000","message":"Well, that the VMT use the branches is circular: they have to use them to provide fixes for them, that they can do so is not a benefit of the branch. If the branches didn\u0027t exist, that work would not need to be done - point 2 in costs. Added your framing.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"4c3efb7398fc226c2e4b096a1c6f28d13809b63d","unresolved":false,"context_lines":[{"line_number":144,"context_line":"the client changes, but separate tests should be put in place for changes to"},{"line_number":145,"context_line":"the requirements repository."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"However, as pip doesn\u0027t actually detect conflicts, we\u0027ll also need to write a"},{"line_number":148,"context_line":"simple algebraic test that makes sure that any lower bounds are compatible"},{"line_number":149,"context_line":"with the global-requirements and upper-constraints in all older supported"},{"line_number":150,"context_line":"releases of OpenStack."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_50f4ddf0","line":147,"updated":"2015-11-18 00:52:34.000000000","message":"Or get that dep. solver in ;)","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":13134,"name":"Joe D\u0027Andrea","email":"jdandrea@redhat.com","username":"jdandrea"},"change_message_id":"7d2ffd492b403fdef4c83ea460b7bc1892c5dfd8","unresolved":false,"context_lines":[{"line_number":155,"context_line":"Versioning of releases"},{"line_number":156,"context_line":"----------------------"},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Stable branchs are only permitted to use point version numbers; this means"},{"line_number":159,"context_line":"that changes to requirements in stable branches have to be treated as point"},{"line_number":160,"context_line":"releases (or prohibited), otherwise the master / next branch up of the same"},{"line_number":161,"context_line":"project will cut releases with the same version numbers."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_308599ac","line":158,"updated":"2015-11-23 21:58:46.000000000","message":"branchs -\u003e branches","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"f97a841ddab05c47c78fc274f8157bbf0f9c151b","unresolved":false,"context_lines":[{"line_number":173,"context_line":""},{"line_number":174,"context_line":"For servers we have master(m) and release branches(r)"},{"line_number":175,"context_line":"For clients/libraries we have master(m), latest release(l),"},{"line_number":176,"context_line":"release-at-the-time-a-server-branch-was-made(r)"},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"In order to test changes to a given server branch with both the matching"},{"line_number":179,"context_line":"client/library release, and either master or latest release, we need a few"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_7e2a5480","line":176,"updated":"2015-12-01 07:28:27.000000000","message":"what about new releases to stable branches? we often cut keystonemiddleware/keystoneclient for stable/kilo and stable/liberty.\n\nnot sure if that is included in your definition here","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":173,"context_line":""},{"line_number":174,"context_line":"For servers we have master(m) and release branches(r)"},{"line_number":175,"context_line":"For clients/libraries we have master(m), latest release(l),"},{"line_number":176,"context_line":"release-at-the-time-a-server-branch-was-made(r)"},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"In order to test changes to a given server branch with both the matching"},{"line_number":179,"context_line":"client/library release, and either master or latest release, we need a few"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_fdaa9318","line":176,"in_reply_to":"9a8ffd7b_7e2a5480","updated":"2015-12-02 00:22:00.000000000","message":"An older version of the spec proposed stopping branches of libraries and clients; this prose was not updated and I will do so now. I did add the relevant jobs below though.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"6916f38c7a9173cfe3b8b4908f6ce6b806bd9c1b","unresolved":false,"context_lines":[{"line_number":230,"context_line":""},{"line_number":231,"context_line":"Changes to stable and master clients/libraries should run:"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"1. A test of each preceeding suppport server branch using the latest releases in"},{"line_number":234,"context_line":"   \u0027upper-constraints.txt\u0027 + the modified client/library. \"Does this change"},{"line_number":235,"context_line":"   work with all our supported server branches that were created before this"},{"line_number":236,"context_line":"   branch\". It offers some limited testing on whether it works with all our"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_1f3f8fb5","line":233,"updated":"2015-11-24 20:46:49.000000000","message":"s/suppport/support/","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3778837507ba65bf9e7c5f41cc7ca78140ee2dc0","unresolved":false,"context_lines":[{"line_number":253,"context_line":"----------------------"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Distributors can keep using stable client and library branches, so no impact."},{"line_number":256,"context_line":"Its possible that having less accidental backwards compat breakages will make"},{"line_number":257,"context_line":"the backporting process easier, but that is just speculation."},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_c4b0378e","line":256,"updated":"2015-12-01 15:45:34.000000000","message":"change \"Its\" to \"It\u0027s\"","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":253,"context_line":"----------------------"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Distributors can keep using stable client and library branches, so no impact."},{"line_number":256,"context_line":"Its possible that having less accidental backwards compat breakages will make"},{"line_number":257,"context_line":"the backporting process easier, but that is just speculation."},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_2c922ea0","line":256,"in_reply_to":"9a8ffd7b_c4b0378e","updated":"2015-12-02 00:22:00.000000000","message":"Done","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"2098dff2e83deb08adae52d79c5e35056c889bf0","unresolved":false,"context_lines":[{"line_number":279,"context_line":"instability in new code impacting existing features, and that would make"},{"line_number":280,"context_line":"upgrades riskier for deployers - and they are already hard enough and risky"},{"line_number":281,"context_line":"enough that this was considered to be a poor tradeoff overall, at least for"},{"line_number":282,"context_line":"now."},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"Implementation"},{"line_number":285,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba8a016a_b062e9ab","line":282,"updated":"2015-11-18 00:54:36.000000000","message":"+1 maybe someday, not likely soon.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"17fb8fcc4c0eedfd1163306093cce6e514195de3","unresolved":false,"context_lines":[{"line_number":291,"context_line":"  Lifeless will be sheparding this but hoping to collaborate with as many"},{"line_number":292,"context_line":"  interested folk as possible."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Work Items"},{"line_number":295,"context_line":"----------"},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Work items or tasks -- break the feature up into the things that need"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_85625215","line":294,"updated":"2015-12-01 03:14:56.000000000","message":"As a PTL of a project, what can one do to facilitate this initiative in the context of the project the person is PTL of? I understand that this is mostly infrastructure plumbing that has to happen, but is there specific work that has to happen within the repos that the PTL has oversight of?","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"b0172763db1ee17f1b2cc85a9fcf0776c51457c7","unresolved":false,"context_lines":[{"line_number":291,"context_line":"  Lifeless will be sheparding this but hoping to collaborate with as many"},{"line_number":292,"context_line":"  interested folk as possible."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Work Items"},{"line_number":295,"context_line":"----------"},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Work items or tasks -- break the feature up into the things that need"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_a2070780","line":294,"in_reply_to":"9a8ffd7b_42b41bf1","updated":"2015-12-02 01:28:01.000000000","message":"If you\u0027d like python-neutronclient to be the guinea pig, feel free to give me a shout!","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"407f684fa4dcbdb8617986fbf2bc3ccf47c0b3e1","unresolved":false,"context_lines":[{"line_number":291,"context_line":"  Lifeless will be sheparding this but hoping to collaborate with as many"},{"line_number":292,"context_line":"  interested folk as possible."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Work Items"},{"line_number":295,"context_line":"----------"},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Work items or tasks -- break the feature up into the things that need"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_d829dd8a","line":294,"in_reply_to":"9a8ffd7b_85625215","updated":"2015-12-02 00:22:00.000000000","message":"Fix any existing incompatibilities - basically this will show up as we add jobs non-voting, and having those be prioritised would be great.  Will add some prose here.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"bf1ed26e9b99f2133d9c72400daf7ca63dc7c82d","unresolved":false,"context_lines":[{"line_number":291,"context_line":"  Lifeless will be sheparding this but hoping to collaborate with as many"},{"line_number":292,"context_line":"  interested folk as possible."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Work Items"},{"line_number":295,"context_line":"----------"},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Work items or tasks -- break the feature up into the things that need"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_42b41bf1","line":294,"in_reply_to":"9a8ffd7b_ac34defa","updated":"2015-12-02 01:18:59.000000000","message":"I expect we\u0027ll pick something like oslo.messaging, or python-novaclient, and get it all sorted there, and then document + ask folk to scale out, like we\u0027re doing with -constraints jobs.","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0be85a9b974d925f9fef2056d2794b054db4906a","unresolved":false,"context_lines":[{"line_number":291,"context_line":"  Lifeless will be sheparding this but hoping to collaborate with as many"},{"line_number":292,"context_line":"  interested folk as possible."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Work Items"},{"line_number":295,"context_line":"----------"},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Work items or tasks -- break the feature up into the things that need"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_ac34defa","line":294,"in_reply_to":"9a8ffd7b_d829dd8a","updated":"2015-12-02 00:37:44.000000000","message":"Do you envision this to happen in the span of a single release? How do you plan to track it? Common topic, blueprint? Would you offer an initial pattern that the individual projects would follow? (like for instance it was done for reno?)","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"f97a841ddab05c47c78fc274f8157bbf0f9c151b","unresolved":false,"context_lines":[{"line_number":303,"context_line":"Dependencies"},{"line_number":304,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"- Include specific references to specs and/or blueprints in OpenStack,"},{"line_number":307,"context_line":"  or in other projects, that this one either depends on or is related"},{"line_number":308,"context_line":"  to."},{"line_number":309,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9a8ffd7b_433f7dd6","line":306,"updated":"2015-12-01 07:28:27.000000000","message":"remove boilerplate","commit_id":"0504f2f17b768b7ac42eb1632dd01edb1348275c"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"346119e7b98a2e0c579d7e059708e05c63780b7b","unresolved":false,"context_lines":[{"line_number":15,"context_line":"Note that this is separate to HTTP API concerns, where the API is on different"},{"line_number":16,"context_line":"machines to the client, and deployments may be static for many years, leading"},{"line_number":17,"context_line":"to a different set of concerns and considerations, which will be addressed in"},{"line_number":18,"context_line":"a separate, later specification."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Proposed change"},{"line_number":21,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_9fd304d5","line":18,"updated":"2015-12-02 19:11:23.000000000","message":"I\u0027m not really sure where it would come in here, but I would like to get an idea with a concrete example of how problems in the past (or current) will be resolved with this new process.\n\nSpecifically (since it\u0027s recent and broken neutron in stable/liberty - broken functionally, not a co-install issue):\n\nhttps://review.openstack.org/#/c/247906/\n\nThat\u0027s the thing where neutron in liberty is using internal modules from oslo.messaging and when o.m 2.6.0 was released and removed those, it broke neutron stable/liberty.  We added an alias for those in o.m 3.0 to fix neutron stable/liberty, and blacklisted o.m 2.6-\u003e3.0 in stable/liberty g-r, but I\u0027m wondering at what point we can remove those stubs from o.m and not break neutron stable/liberty again - that is if we don\u0027t cap o.m in stable/liberty.\n\nThat might be liberty-eol.  That might mean capping o.m on 4.0 or whatever major release drops the alias in o.m.  But since we didn\u0027t have test coverage for it and it wasn\u0027t an install issue, I\u0027m assuming we won\u0027t notice again if it\u0027s removed and breaks again w/o the cap in place.","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d9cdfed78c80a2306df1214342a8f2dc93e4fd7e","unresolved":false,"context_lines":[{"line_number":15,"context_line":"Note that this is separate to HTTP API concerns, where the API is on different"},{"line_number":16,"context_line":"machines to the client, and deployments may be static for many years, leading"},{"line_number":17,"context_line":"to a different set of concerns and considerations, which will be addressed in"},{"line_number":18,"context_line":"a separate, later specification."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Proposed change"},{"line_number":21,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_0427c8b6","line":18,"in_reply_to":"9a8ffd7b_7ef9817f","updated":"2015-12-02 20:10:20.000000000","message":"\"So - o.m would not have been able to pass CI with the test matrix this proposes\"\n\nSince this wasn\u0027t a co-install issue, and there don\u0027t appear to be tests that cover these oslo.messaging notification entries in neutron, I\u0027m not sure how that would have caught this?","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"13f76aa853cfc784447189975cd30c0820a1efee","unresolved":false,"context_lines":[{"line_number":15,"context_line":"Note that this is separate to HTTP API concerns, where the API is on different"},{"line_number":16,"context_line":"machines to the client, and deployments may be static for many years, leading"},{"line_number":17,"context_line":"to a different set of concerns and considerations, which will be addressed in"},{"line_number":18,"context_line":"a separate, later specification."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Proposed change"},{"line_number":21,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_7ef9817f","line":18,"in_reply_to":"9a8ffd7b_9fd304d5","updated":"2015-12-02 19:45:27.000000000","message":"So - o.m would not have been able to pass CI with the test matrix this proposes. That would then have provided signal so the o.m developers could address this - e.g. by providing the needed alias from the get-go, rather than in reaction to breaking liberty when it released.\n\nThat then leads to no need to blacklist in liberty g-r.\n\nThe compat stubs would be marked with a deprecation warning, and can be removed when we remove the last users of it from a supported release - e.g. liberty eol.\n\nSince we\u0027ll have a good upper-constraints in liberty at all times, there\u0027s no need to go back and cap things: should someone be wanting to pick it up and do stuff with it, all the information about whats works is already available and documented.","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"346119e7b98a2e0c579d7e059708e05c63780b7b","unresolved":false,"context_lines":[{"line_number":150,"context_line":"Requirements management"},{"line_number":151,"context_line":"-----------------------"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"We need to ensure that master clients/libraries are co-installable with all"},{"line_number":154,"context_line":"supported releases. A solid test matrix will also test co-installability on"},{"line_number":155,"context_line":"the client changes, but separate tests should be put in place for changes to"},{"line_number":156,"context_line":"the requirements repository."}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_3fdf786a","line":153,"updated":"2015-12-02 19:11:23.000000000","message":"Install is not always the issue, as seen here:\n\nhttps://review.openstack.org/#/c/247199/","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"13f76aa853cfc784447189975cd30c0820a1efee","unresolved":false,"context_lines":[{"line_number":150,"context_line":"Requirements management"},{"line_number":151,"context_line":"-----------------------"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"We need to ensure that master clients/libraries are co-installable with all"},{"line_number":154,"context_line":"supported releases. A solid test matrix will also test co-installability on"},{"line_number":155,"context_line":"the client changes, but separate tests should be put in place for changes to"},{"line_number":156,"context_line":"the requirements repository."}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_1ef4f558","line":153,"in_reply_to":"9a8ffd7b_3fdf786a","updated":"2015-12-02 19:45:27.000000000","message":"Sure, I didn\u0027t say it was the only issue ;). This spec isn\u0027t rewriting all the requirements management policies; its addressing the specific things related to backwards compat which are:\n a) testing to avoid the breaks that that review is addressing\n b) being able to describe both stable-good and latest-good as constraints files - needed for the testing matrix","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"346119e7b98a2e0c579d7e059708e05c63780b7b","unresolved":false,"context_lines":[{"line_number":160,"context_line":"with the global-requirements and upper-constraints in all older supported"},{"line_number":161,"context_line":"releases of OpenStack."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Minimums can thus be raised as long as there are no caps or incompatibilities"},{"line_number":164,"context_line":"preventing the new minimum being used in supported branches."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Libraries/clients that decide not to provide backwards compatibility need to"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_3fe9b8e6","line":163,"updated":"2015-12-02 19:11:23.000000000","message":"I\u0027m always loath to raise the minimum required version of a library/client in stable branches because of conservative deployments that have shipped, let\u0027s say, Kilo, with their own packages, and there is no functional reason for them to update those clients/libraries in their Kilo distribution.  It\u0027s actually not something you\u0027d want to do since it can increase the risk for regression and security impacts with newer code that hasn\u0027t had as much time to burn in with the older release.\n\nAnyway, I see raising minimums on dependencies in stable as a last resort if we have to fix a bug.","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"13f76aa853cfc784447189975cd30c0820a1efee","unresolved":false,"context_lines":[{"line_number":160,"context_line":"with the global-requirements and upper-constraints in all older supported"},{"line_number":161,"context_line":"releases of OpenStack."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"Minimums can thus be raised as long as there are no caps or incompatibilities"},{"line_number":164,"context_line":"preventing the new minimum being used in supported branches."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"Libraries/clients that decide not to provide backwards compatibility need to"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_7e8ae1c0","line":163,"in_reply_to":"9a8ffd7b_3fe9b8e6","updated":"2015-12-02 19:45:27.000000000","message":"I will rephrase this: I did not mean raising them in stable branches, rather in master. \"Minimums in master can thus be raised as long as there are no caps....\"","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"346119e7b98a2e0c579d7e059708e05c63780b7b","unresolved":false,"context_lines":[{"line_number":167,"context_line":"be managed in our global requirements using upper pins: this has a high cost"},{"line_number":168,"context_line":"(see above), but since we know they will break regularly, we don\u0027t ever need"},{"line_number":169,"context_line":"to uncap it, and so we won\u0027t be doing the release-time-mass-dance that our"},{"line_number":170,"context_line":"previous cap-at-release time process used: instead they will be capped at all"},{"line_number":171,"context_line":"times."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"Versioning of releases"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_ffeed0eb","line":170,"updated":"2015-12-02 19:11:23.000000000","message":"+1 to this.","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"346119e7b98a2e0c579d7e059708e05c63780b7b","unresolved":false,"context_lines":[{"line_number":191,"context_line":""},{"line_number":192,"context_line":"For servers we have master and release branches"},{"line_number":193,"context_line":"For clients/libraries we have master, latest release,"},{"line_number":194,"context_line":"release-at-the-time-a-server-branch-was-made and release branches"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"In order to test changes to a given server branch with both the matching"},{"line_number":197,"context_line":"client/library release, and either master or latest release, we need a few"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a8ffd7b_bf892828","line":194,"updated":"2015-12-02 19:11:23.000000000","message":"s/release branches/stable branches/?","commit_id":"b5d3e1a958bdfdab3beeae8253dbbaf9582f3a6a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7417b5a722eff7c194b42f92d572cafce53b791f","unresolved":false,"context_lines":[{"line_number":301,"context_line":"library in an old release - but as this would make co-installability of"},{"line_number":302,"context_line":"current releases of anything that depends on that library impossible in short"},{"line_number":303,"context_line":"order, this would be equivalent to end-of-lifing the old release, and so that"},{"line_number":304,"context_line":"should be preferred. In the cases where such co-installability will not be an"},{"line_number":305,"context_line":"issue, a cap would be tolerable."},{"line_number":306,"context_line":""},{"line_number":307,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":10,"id":"9a8ffd7b_8f143144","line":304,"updated":"2015-12-02 20:27:11.000000000","message":"s/preferred/avoided/?","commit_id":"e6da21a268d6b0bd5aafd810bfc11d95fe6812b5"},{"author":{"_account_id":2537,"name":"Nikhil Komawar","email":"nik.komawar@gmail.com","username":"nikhil-komawar"},"change_message_id":"eed83dc7ca164d91ff6d5db4b2fec27648e79b0c","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  stable maintenance team decide to maintain each stable branch for.  Branches"},{"line_number":39,"context_line":"  that are no longer maintained will have a known-good set of dependency"},{"line_number":40,"context_line":"  versions from the point at which maintenance and support stopped, which will"},{"line_number":41,"context_line":"  remain valid indefinitely."},{"line_number":42,"context_line":"* Commit to, and test, co-installability of each library back to the oldest"},{"line_number":43,"context_line":"  supported OpenStack branch."},{"line_number":44,"context_line":"* Libraries cannot be added to global-requirements with uncapped versions"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7a740942_d016a0a6","line":41,"updated":"2015-12-06 04:45:24.000000000","message":"I have a query regarding the enforcement of such a process on particularly `glance_store` lib.\n\nWhile I understand that this doesn\u0027t necessarily fir the description of a library mentioned in point #1 (line 26 above), there\u0027s some split in community that wants this library where one want it to be generic and other part want it to marry to glance.\n\nWhile we get to decide that in the future, I think at this point it would be good to know of such commitments for say a major refactor to the API ( https://review.openstack.org/#/c/188050/ ). \n\nWould the glance community be stuck with maintaining such a refactored API for 4 cycles or will a fix-things-make-them-smooth transition lead the way into deprecation within 1 or max 2 cycles?","commit_id":"6553e08ec5759cb90cee45eab345073ee59681b1"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"45037bb53ddf81021b2236df7dfda453eefdccb2","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  stable maintenance team decide to maintain each stable branch for.  Branches"},{"line_number":39,"context_line":"  that are no longer maintained will have a known-good set of dependency"},{"line_number":40,"context_line":"  versions from the point at which maintenance and support stopped, which will"},{"line_number":41,"context_line":"  remain valid indefinitely."},{"line_number":42,"context_line":"* Commit to, and test, co-installability of each library back to the oldest"},{"line_number":43,"context_line":"  supported OpenStack branch."},{"line_number":44,"context_line":"* Libraries cannot be added to global-requirements with uncapped versions"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7a740942_87753599","line":41,"in_reply_to":"7a740942_d016a0a6","updated":"2015-12-06 21:00:24.000000000","message":"So - if glance_store is a _private_ library, then you can argue that all bets are off. However, if its being consumed at all by any other projects, then whatever the original intent, its become an API folk are consuming, and all the skew and interactions we see with other things becomes possible.\n\nSo - I don\u0027t think the axis that matters is \u0027tied to glance\u0027-\u0027generic\u0027, the axis that matters is \u0027consumed solely by glance\u0027-\u0027consumed by other projects\u0027 (and that can be hard to actually tell).\n\nThe conservative thing to do would be to manage its backwards compatibility concerns the same as everything else - and that spec that you pointed at does in fact do that (yay!).\n\nIf however it becomes apparent that its way too much of a burden a year or two down the track, we can always go back to the old supported releases and and exclude or even cap it there - though doing that *won\u0027t help* folk that haven\u0027t upgraded to the next point release of that thing - so its at best a partial band aid. (OTOH when things stop being supported we\u0027re saying we\u0027re free to cause havoc anyway, so clearly there are a range of tradeoffs to be made at any point, and we\u0027ll have to see what comes)","commit_id":"6553e08ec5759cb90cee45eab345073ee59681b1"},{"author":{"_account_id":10980,"name":"Doug Wiegley","email":"dougwig@parkside.io","username":"dougw"},"change_message_id":"9579b1f9f5eef19a68ea81332c09dcbd709070b6","unresolved":false,"context_lines":[{"line_number":348,"context_line":""},{"line_number":349,"context_line":"3. Migrate them to voting as soon as possible."},{"line_number":350,"context_line":""},{"line_number":351,"context_line":""},{"line_number":352,"context_line":"Dependencies"},{"line_number":353,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":354,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"7a740942_66e172fe","line":351,"updated":"2015-12-09 22:31:12.000000000","message":"Perhaps a governance tag for complying libs?","commit_id":"6553e08ec5759cb90cee45eab345073ee59681b1"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"0ae76b4b2cfa41faef970ed094bd03f2ff869c10","unresolved":false,"context_lines":[{"line_number":348,"context_line":""},{"line_number":349,"context_line":"3. Migrate them to voting as soon as possible."},{"line_number":350,"context_line":""},{"line_number":351,"context_line":""},{"line_number":352,"context_line":"Dependencies"},{"line_number":353,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":354,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"7a740942_dd8df431","line":351,"in_reply_to":"7a740942_469e8fb9","updated":"2015-12-14 05:28:17.000000000","message":"sure, I can add that - I don\u0027t want to wipe out the existing votes, so will do this when its at TC signoff point.","commit_id":"6553e08ec5759cb90cee45eab345073ee59681b1"},{"author":{"_account_id":2537,"name":"Nikhil Komawar","email":"nik.komawar@gmail.com","username":"nikhil-komawar"},"change_message_id":"947638ba982094009150eaf5e6142482741ac87e","unresolved":false,"context_lines":[{"line_number":348,"context_line":""},{"line_number":349,"context_line":"3. Migrate them to voting as soon as possible."},{"line_number":350,"context_line":""},{"line_number":351,"context_line":""},{"line_number":352,"context_line":"Dependencies"},{"line_number":353,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":354,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"7a740942_469e8fb9","line":351,"in_reply_to":"7a740942_66e172fe","updated":"2015-12-10 14:19:32.000000000","message":"+1","commit_id":"6553e08ec5759cb90cee45eab345073ee59681b1"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"7c4e7f40eeed671e8e3a89490baccf917985d846","unresolved":false,"context_lines":[{"line_number":23,"context_line":"Summary"},{"line_number":24,"context_line":"-------"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* Keep backwards compatibility with all supported branches of all of OpenStack"},{"line_number":27,"context_line":"  in all our non-server-coupled libraries. (That is, novaclient is included,"},{"line_number":28,"context_line":"  ironic-lib is not). Currently client libraries aim at this but we don\u0027t"},{"line_number":29,"context_line":"  test sufficiently to deliver this. Oslo doesn\u0027t currently commit to this,"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_85005503","line":26,"updated":"2016-01-13 02:36:50.000000000","message":"one release except clients all releases","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"8b3bb77511ac97fe4a51b5a0a4011e83e967b8d8","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  ironic-lib is not). Currently client libraries aim at this but we don\u0027t"},{"line_number":29,"context_line":"  test sufficiently to deliver this. Oslo doesn\u0027t currently commit to this,"},{"line_number":30,"context_line":"  and the growing number of non-oslo libraries have per-project policies."},{"line_number":31,"context_line":"  We\u0027ll test this through devstack cross-release tests."},{"line_number":32,"context_line":"* Keep master always releasable (we already aim at this)."},{"line_number":33,"context_line":"* Commit to, and test, co-installability and compatibility of each library back"},{"line_number":34,"context_line":"  to the oldest supported OpenStack branch."}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_b1101f5b","line":31,"updated":"2016-01-07 13:35:52.000000000","message":"\"devstack and grenade cross-release tests.\" would be better i think","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"defa21be8513129ead94d8ffb5cbad23c74c103c","unresolved":false,"context_lines":[{"line_number":53,"context_line":"branches would require two key things - that we don\u0027t have API breaks on"},{"line_number":54,"context_line":"master, and that new features introduced do not cause instabilities, and we"},{"line_number":55,"context_line":"have no plan for preventing such instabilities, therefore we cannot stop"},{"line_number":56,"context_line":"having stable branches."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"status quo details"},{"line_number":59,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"da6ed579_992da248","line":56,"updated":"2016-01-13 14:40:25.000000000","message":"I assume in this paragraph that \"we\" is upstream OpenStack. Which suggests the question: Why are stable branches of anything a upstream responsibility? Why not let it be a way in which distributors and packagers distinguish themselves in the market place?\n\nI\u0027m not suggesting that \"we\" take the approach of not managing stable, but I feel like it is important to answer those questions in order to effectively orchestrate our resources when it comes to \"stability\" as well as to fully articulate the issues so we aren\u0027t merely taking \"stable\" as dogma.\n\nSome of this is addressed below, which is good, but it might well do with being front and center.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"8b3bb77511ac97fe4a51b5a0a4011e83e967b8d8","unresolved":false,"context_lines":[{"line_number":68,"context_line":"+++++++++++++++++++++++"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The lack of strong consistent backwards compatibility shows up as a number of"},{"line_number":71,"context_line":"individual issues:"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"1. Upper caps in stable branches lead to regular repeated deadlocks and gate"},{"line_number":74,"context_line":"   failures. The work we\u0027ve done with constraints mitigates this, but we still"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_b4f1ed03","line":71,"updated":"2016-01-07 13:35:52.000000000","message":"Do we want to highlight rolling upgrades here?","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c5b5f3ac494d912f3490bc60cd784257e25a9dbd","unresolved":false,"context_lines":[{"line_number":70,"context_line":"The lack of strong consistent backwards compatibility shows up as a number of"},{"line_number":71,"context_line":"individual issues:"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"1. Upper caps in stable branches lead to regular repeated deadlocks and gate"},{"line_number":74,"context_line":"   failures. The work we\u0027ve done with constraints mitigates this, but we still"},{"line_number":75,"context_line":"   can\u0027t use upper caps except where we can guarantee that we will be able to"},{"line_number":76,"context_line":"   preserve overlapping regions across all upgrades. The lack of a reliable"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_20085391","line":73,"updated":"2016-01-07 15:02:30.000000000","message":"Here is another example where not having caps fails us:\n\nhttps://review.openstack.org/#/c/264793/\n\nhttps://review.openstack.org/#/c/246792/ passed unit tests in nova stable/liberty because it ran with an uncapped oslo.serialization 1.11.0:\n\nhttp://logs.openstack.org/92/246792/1/check/gate-nova-python27/4a49d36/console.html.gz#_2015-11-19_02_17_48_881\n\nThe dump_as_bytes method was added in 1.10.0.\n\nThe g-r min in oslo.serialization in stable/liberty is 1.4.0:\n\nhttps://github.com/openstack/requirements/blob/stable/liberty/global-requirements.txt#L98\n\nIf we would have capped stable/liberty g-r oslo.serialization at \u003c1.5, the unit tests would have failed in the nova backport.\n\nNote the constraints jobs didn\u0027t run on the nova backport, but even if they would have, they would have passed since upper-constraints in stable/liberty for oslo.serialization is 2.1.0:\n\nhttps://github.com/openstack/requirements/blob/stable/liberty/upper-constraints.txt#L200\n\nSo again, I\u0027m not sure why stable *needs* to work with the latest and greatest master branch library releases, it just exposes stable to errors from lack of lower bounds testing and not having caps.\n\nAnd there was no backwards incompatible change in oslo.serialization on master that would have broken stable/liberty here.\n\nMaybe we could argue that upper-constraints being updated on stable/liberty in https://review.openstack.org/#/c/232918/ is part of the problem. Before that, the upper-constraint on oslo.serialization was 1.9.0 and if we had the -constraints job on that change in stable/liberty, it would have failed since the dump_as_bytes method came in 1.10.0.\n\nStill, that leaves a gap in testing between oslo.serialization  1.4.0 and 1.9.0, so I\u0027m not convinced not capping here is better or anything would catch those kinds of problems.\n\nAnother point - the nova backport ran the postgres job which runs the metadata service and that should have caught this problem, except, again, that\u0027s using upper-constraints so it\u0027s pulling in 1.11.0:\n\nhttp://logs.openstack.org/92/246792/1/check/gate-tempest-dsvm-postgres-full/1f33f91/logs/pip-freeze.txt.gz\n\nSo things work but wouldn\u0027t work with the min bound 1.4.0.\n\nSo I think there is something fundamentally flawed in what we\u0027re trying to achieve here, or what our goals are.  I\u0027ve pointed out several breaks in stable since this spec has been up for review and I\u0027m not convinced that the process laid out here is going to prevent those like capping would have.\n\nIf we\u0027re still going forward with this I think there at least needs to be some serious consideration put into lower-bounds testing in the gate on stable changes. Maybe that\u0027s where the release-constraints file comes into play, but as it stands, that\u0027s still just a snapshot of upper-constraints at the time of liberty GA. That would at least have caught this case with nova, but still, oslo.serialization in upper-constraints at the time of liberty GA is 1.9.0 so you still have this gap of 1.4.0 to 1.9.0, there is no construct for lower bound testing based on just what\u0027s in global-requirements.\n\nSo I\u0027m still -1 on this spec since I don\u0027t think it helps prevent failures in stable/liberty like capping did. Sure backwards compat is ideally a good goal, and I think preserving backward compat for n-1 releases is good for a deprecation cycle and then you can drop things with a major version bump - but if we would cap requirements in stable we wouldn\u0027t be affected by major version changes anyway.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"defa21be8513129ead94d8ffb5cbad23c74c103c","unresolved":false,"context_lines":[{"line_number":82,"context_line":"   that transition all components need to be both co-installable and mutually"},{"line_number":83,"context_line":"   compatible. Note that distributions that package each release only need"},{"line_number":84,"context_line":"   release-to-release compatibility. Distributions that skip releases, or who"},{"line_number":85,"context_line":"   release further apart than our 6-monthly cycle, need wider compatibility"},{"line_number":86,"context_line":"   periods to avoid this friction."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"3. A common scenario is having to upgrade clients to talk to newer clouds, but"}],"source_content_type":"text/x-rst","patch_set":12,"id":"da6ed579_b930a69f","line":85,"updated":"2016-01-13 14:40:25.000000000","message":"Isn\u0027t this yet another example of the way in which distributions are antiquated or obsoleted in the world of software defined infrastructure? ;)/2","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"defa21be8513129ead94d8ffb5cbad23c74c103c","unresolved":false,"context_lines":[{"line_number":94,"context_line":"   force upgrades willy-nilly. With the ongoing disaggregation of the servers"},{"line_number":95,"context_line":"   partial upgrades of clouds will become more common."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"4. A lack of clear backwards compatibility makes encouraging new users tricky"},{"line_number":98,"context_line":"   at best: folk don\u0027t want to be facing broken builds (ever)."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Not being rigorous about backwards compatibility may permit us to move faster"}],"source_content_type":"text/x-rst","patch_set":12,"id":"da6ed579_59272a64","line":97,"updated":"2016-01-13 14:40:25.000000000","message":"+1. I think user-centered justifications have far more weight in this argument than gate or distro-based justifications. As a user I want to be able to pip install my-openstack-client and just use it with any and all of my openstack clouds, old and new.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3f0c5241fea58910ee4d2198533052974da53611","unresolved":false,"context_lines":[{"line_number":207,"context_line":"To match the release done at the time a new branch was created, we need to"},{"line_number":208,"context_line":"constrain the versions installed to those used at that time. We can do this by"},{"line_number":209,"context_line":"copying the upper-constraints.txt to a new file - perhaps"},{"line_number":210,"context_line":"\u0027release-constraints.txt\u0027 within the branch. Then we test with that rather"},{"line_number":211,"context_line":"than \u0027upper-constraints.txt\u0027"},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"Latest release"},{"line_number":214,"context_line":"++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_27c68968","line":211,"range":{"start_line":210,"start_character":45,"end_line":211,"end_character":28},"updated":"2016-01-05 18:45:09.000000000","message":"This is another way of doing what we did in the past at release time where we\u0027d just cap versions in global-requirements. That really failed for 2 main reasons:\n\n1. We would \u003c\u003d to the current version we were testing with, which didn\u0027t leave room for .z releases.\n\n2. We had overlap in versions between stable branches, so stable/juno and stable/kilo could be using the same version of some oslo lib or openstack client package and updating one for kilo would break juno, or vice-versa.\n\n--\n\nI know by the time we go to stable/kilo g-r we were better about #1, or at least fixed a lot of that before it was really painful.\n\nFor #2, I think things have gotten better because of the centralized openstack/releases process and the more keen eye on semantic versioning of package releases and when a minor version needed to be bumped - which if you do #1 properly with the caps, should help isolate the different branches in g-r.\n\nAnyway, I\u0027ve said this all several times to several people, but we were talking about it in IRC again today so I\u0027m just stating again here. In general I\u0027m concerned about the blanket approval of the bot changes to generate-constraints for raising upper-constraints.txt on stable branches - those are approved because jenkins passes but the test runs on those changes are only a subset of what\u0027s actually tested, like in the unit tests of the server projects that use the libs.  Those are using things in the libs that tempest doesn\u0027t cover so we are exposed.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dd90de858762ab34ba914b961be2a1f8613c04d7","unresolved":false,"context_lines":[{"line_number":207,"context_line":"To match the release done at the time a new branch was created, we need to"},{"line_number":208,"context_line":"constrain the versions installed to those used at that time. We can do this by"},{"line_number":209,"context_line":"copying the upper-constraints.txt to a new file - perhaps"},{"line_number":210,"context_line":"\u0027release-constraints.txt\u0027 within the branch. Then we test with that rather"},{"line_number":211,"context_line":"than \u0027upper-constraints.txt\u0027"},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"Latest release"},{"line_number":214,"context_line":"++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_6727a1ca","line":211,"range":{"start_line":210,"start_character":45,"end_line":211,"end_character":28},"in_reply_to":"fa69d971_27c68968","updated":"2016-01-05 18:58:38.000000000","message":"I guess I\u0027d like to see some wording in this spec about why the release-constraints idea is different and better than capping in g-r on stable with sanity, i.e. for stable/liberty don\u0027t cap oslo.messaging\u003c\u003d$version-of-oslo-messaging-at-liberty-release-time.\n\nI\u0027m just not really comfortable with this from a stable maint perspective and how it\u0027s any better, or a packaging perspective for that matter. It seems like we plan on (1) packagers knowing requirements.txt in a project is not trustworthy, at least on the max side and they have to check these other -constraints files in the requirements repo on a given branch and (2) there will be testing that will cover all the things, which is never going to be true. dsvm/tempest jobs test what tempest hits in an API, but there are other entry points in the projects that use things in the libs/clients that tempest doesn\u0027t test - those get tested in a projects functional/unit test jobs, which we don\u0027t test in the bot changes that update upper-constraints.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"8b3bb77511ac97fe4a51b5a0a4011e83e967b8d8","unresolved":false,"context_lines":[{"line_number":209,"context_line":"copying the upper-constraints.txt to a new file - perhaps"},{"line_number":210,"context_line":"\u0027release-constraints.txt\u0027 within the branch. Then we test with that rather"},{"line_number":211,"context_line":"than \u0027upper-constraints.txt\u0027"},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"Latest release"},{"line_number":214,"context_line":"++++++++++++++"},{"line_number":215,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_1409d9dd","line":212,"updated":"2016-01-07 13:35:52.000000000","message":"On some discussions yesterday, there was consensus around....\"If a library has a stable/ branch (say o.vo), then the only o.vo version that can be in release-constraints.txt would be the one released from that stable branch\" can we please add this explicitly?","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ccbd54705832bf99fa25e1ea9678c1a9987fcdc5","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"To test changes to clients/libraries with servers we need to upgrade only the"},{"line_number":222,"context_line":"things that need upgrading - otherwise we\u0027re not testing the impact of"},{"line_number":223,"context_line":"upgrading that client alone. \u0027release-constraints.txt\u0027 acts as a reasonable"},{"line_number":224,"context_line":"starting point, but we need some mechanism to restrict upgrades of components"},{"line_number":225,"context_line":"to versions that have passed constraints testing in master (otherwise new"},{"line_number":226,"context_line":"releases of any component would bypass constraints and result in unchecked"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_020c93eb","line":223,"range":{"start_line":223,"start_character":30,"end_line":223,"end_character":53},"updated":"2016-01-05 19:09:18.000000000","message":"Do we ever raise caps in release-constraints on stable and if so, what are the conditions/triggers for that?  If that\u0027s a possibility, we should probably document it.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"7c4e7f40eeed671e8e3a89490baccf917985d846","unresolved":false,"context_lines":[{"line_number":220,"context_line":""},{"line_number":221,"context_line":"To test changes to clients/libraries with servers we need to upgrade only the"},{"line_number":222,"context_line":"things that need upgrading - otherwise we\u0027re not testing the impact of"},{"line_number":223,"context_line":"upgrading that client alone. \u0027release-constraints.txt\u0027 acts as a reasonable"},{"line_number":224,"context_line":"starting point, but we need some mechanism to restrict upgrades of components"},{"line_number":225,"context_line":"to versions that have passed constraints testing in master (otherwise new"},{"line_number":226,"context_line":"releases of any component would bypass constraints and result in unchecked"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_ea76f5d5","line":223,"range":{"start_line":223,"start_character":30,"end_line":223,"end_character":53},"in_reply_to":"fa69d971_020c93eb","updated":"2016-01-13 02:36:50.000000000","message":"yes, it needs to be a living document as point releases of oslo etc are done: I\u0027ll add that to where we describe release-consraints.txt.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"8b3bb77511ac97fe4a51b5a0a4011e83e967b8d8","unresolved":false,"context_lines":[{"line_number":236,"context_line":"   things transitive dependencies, and only those components - detecting"},{"line_number":237,"context_line":"   undeclared backwards compatibilities. The versions chosen will be those"},{"line_number":238,"context_line":"   known to work in master."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Matrix"},{"line_number":241,"context_line":"++++++"},{"line_number":242,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_d4e021fd","line":239,"updated":"2016-01-07 13:35:52.000000000","message":"Can we add a note that unit tests of say nova in stable branch should only run with release-constraints and NOT upper-constraints? This would prevent a lot of breaks.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"7c4e7f40eeed671e8e3a89490baccf917985d846","unresolved":false,"context_lines":[{"line_number":251,"context_line":"   of our clients/libraries.\""},{"line_number":252,"context_line":""},{"line_number":253,"context_line":"Changes to stable and master clients/libraries should run:"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"1. A test of each preceeding support server branch using the latest releases in"},{"line_number":256,"context_line":"   \u0027upper-constraints.txt\u0027 + the modified client/library. \"Does this change"},{"line_number":257,"context_line":"   work with all our supported server branches that were created before this"}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_a50f9935","line":254,"updated":"2016-01-13 02:36:50.000000000","message":"be specific about what jobs.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"defa21be8513129ead94d8ffb5cbad23c74c103c","unresolved":false,"context_lines":[{"line_number":324,"context_line":"using constraints from upstream)."},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"Dropping stable branches of clients/libraries"},{"line_number":327,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"We could further reduce confusion about versions etc if we didn\u0027t have stable"},{"line_number":330,"context_line":"branches at all. However we have no mechanism at the moment to prevent"}],"source_content_type":"text/x-rst","patch_set":12,"id":"da6ed579_792a2e2e","line":327,"updated":"2016-01-13 14:40:25.000000000","message":"This strategy was somewhat like what I was expecting when I started reading this: Branchless clients that build in backwards compatibility when adding features, and the new gating would be ensuring that this new client code works against all supported server versions. If that was the case I was then expecting this spec to have some advice/examples on how client code might write itself to simultaneously enable optional new features while maintaining the backwards compatibility (in the face of requirements constraints). I can\u0027t decide if I\u0027m disappointed or not.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"defa21be8513129ead94d8ffb5cbad23c74c103c","unresolved":false,"context_lines":[{"line_number":347,"context_line":"----------"},{"line_number":348,"context_line":""},{"line_number":349,"context_line":"1. Add the governance tag assert:follows-library-deprecation. This is a"},{"line_number":350,"context_line":"   separate tag from assert:follows-standard-deprecation because many projects"},{"line_number":351,"context_line":"   like Neutron both ship libraries and ship servers, and it is unfair to"},{"line_number":352,"context_line":"   retroactively convert a commitment to follow the server deprecation process"},{"line_number":353,"context_line":"   into a commitment to follow this process."}],"source_content_type":"text/x-rst","patch_set":12,"id":"da6ed579_19221253","line":350,"updated":"2016-01-13 14:40:25.000000000","message":"3.5 fix the broken stuff","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"a860d5e2bb9f26fe2e52b35f3be77fb8d579a043","unresolved":false,"context_lines":[{"line_number":350,"context_line":"   separate tag from assert:follows-standard-deprecation because many projects"},{"line_number":351,"context_line":"   like Neutron both ship libraries and ship servers, and it is unfair to"},{"line_number":352,"context_line":"   retroactively convert a commitment to follow the server deprecation process"},{"line_number":353,"context_line":"   into a commitment to follow this process."},{"line_number":354,"context_line":""},{"line_number":355,"context_line":"2. Add release-constraints to liberty requirements."},{"line_number":356,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a7e1126_b5f6f05a","line":353,"updated":"2015-12-21 16:15:22.000000000","message":"follows-standard-deprecation is applied at deliverable level, so libraries currently don\u0027t have it... Expanding the \"common deprecation policy\" with rules applicable to libraries and then applying the tag to the library deliverables of a given project is therefore totally an option.","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"7c4e7f40eeed671e8e3a89490baccf917985d846","unresolved":false,"context_lines":[{"line_number":354,"context_line":""},{"line_number":355,"context_line":"2. Add release-constraints to liberty requirements."},{"line_number":356,"context_line":""},{"line_number":357,"context_line":"3. Add in the jobs from the matrix, to all projects, non-voting."},{"line_number":358,"context_line":""},{"line_number":359,"context_line":"4. Migrate them to voting as soon as possible."},{"line_number":360,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"fa69d971_688f3875","line":357,"updated":"2016-01-13 02:36:50.000000000","message":"don\u0027t permit anything other than point releases to openstack things in release-constraints.txt","commit_id":"033b79b5fd8eeb4002a4e63396cb68c279fd8ed8"}]}