)]}'
{"specs/liberty/feature-based-releases.rst":[{"author":{"_account_id":9315,"name":"ramesh","email":"rameshg87@gmail.com","username":"rameshg87"},"change_message_id":"ccfd06442fc6399e13d2a5f32a697e3fa4a00089","unresolved":false,"context_lines":[{"line_number":54,"context_line":""},{"line_number":55,"context_line":"There are a few things of note here."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":58,"context_line":"  the master branch."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"* We should continue to release a \"stable\" release every six months,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_cc165c4b","line":57,"updated":"2015-05-23 00:42:17.000000000","message":"I think we should talk more about \n* when and how do we decide we have enough content for a feature release - I hope we still do that at the start of a feature release.\n* how do we get to general agreement (irc meeting ?)\n\nI hope we don\u0027t decide set strict timelines (and that\u0027s the main point here)","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0b008dea24f9977de13253e16c953c2cf7a3e2a7","unresolved":false,"context_lines":[{"line_number":54,"context_line":""},{"line_number":55,"context_line":"There are a few things of note here."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":58,"context_line":"  the master branch."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"* We should continue to release a \"stable\" release every six months,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_b3613807","line":57,"in_reply_to":"7a016987_cc165c4b","updated":"2015-05-24 15:24:08.000000000","message":"+1, don\u0027t let me forget about these comments as they aren\u0027t on the latest patch set :)","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":9315,"name":"ramesh","email":"rameshg87@gmail.com","username":"rameshg87"},"change_message_id":"ccfd06442fc6399e13d2a5f32a697e3fa4a00089","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  \"normal\" Ironic release that happens around the same time that other"},{"line_number":65,"context_line":"  integrated projects begin feature freeze."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":68,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":69,"context_line":"  releases in between. (What do folks think about this?)"},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_ec21189f","line":67,"updated":"2015-05-23 00:42:17.000000000","message":"I kind of disagree on this.  If we are doing our own feature independent release and are \"integrated openstack\" releases play no role in Ironic, why should we allow that to bump up the version ? In my opinion, an integrated shouldn\u0027t affect the versions and ironic version should purely be decided on the content delivered.","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0b008dea24f9977de13253e16c953c2cf7a3e2a7","unresolved":false,"context_lines":[{"line_number":64,"context_line":"  \"normal\" Ironic release that happens around the same time that other"},{"line_number":65,"context_line":"  integrated projects begin feature freeze."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":68,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":69,"context_line":"  releases in between. (What do folks think about this?)"},{"line_number":70,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_935cfc4b","line":67,"in_reply_to":"7a016987_ec21189f","updated":"2015-05-24 15:24:08.000000000","message":"I think I agree with you here; this is something a few of us briefly discussed, I\u0027m okay with not doing it.","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":9315,"name":"ramesh","email":"rameshg87@gmail.com","username":"rameshg87"},"change_message_id":"ccfd06442fc6399e13d2a5f32a697e3fa4a00089","unresolved":false,"context_lines":[{"line_number":68,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":69,"context_line":"  releases in between. (What do folks think about this?)"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":74,"context_line":"  should just work on specs and code continuously. Features will be released"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_8c1ce46a","line":71,"updated":"2015-05-23 00:42:17.000000000","message":"+1","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":9315,"name":"ramesh","email":"rameshg87@gmail.com","username":"rameshg87"},"change_message_id":"ccfd06442fc6399e13d2a5f32a697e3fa4a00089","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":75,"context_line":"  as they land."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":78,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"},{"line_number":79,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":80,"context_line":"  changes should be okay to land in most cases."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_ec58f832","line":77,"updated":"2015-05-23 00:42:17.000000000","message":"* If we had already decided on the features for a release, extra risky code is less chance.  \n* If there is riskiness as part of features, then it\u0027s understandable and should be given more time to stabilise (rather than not landing that feature)\n* The only thing left out is a critical bugs that should be allowed to get in based on it\u0027s merit.","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":9315,"name":"ramesh","email":"rameshg87@gmail.com","username":"rameshg87"},"change_message_id":"ccfd06442fc6399e13d2a5f32a697e3fa4a00089","unresolved":false,"context_lines":[{"line_number":79,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":80,"context_line":"  changes should be okay to land in most cases."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"* ??? Anything else?"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Alternatives"},{"line_number":85,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_8c4aa453","line":82,"updated":"2015-05-23 00:42:17.000000000","message":"* Is python-ironicclient still independent of a feature release of ironic ?\n* How to deliver nova virt driver changes that are dependent on ironic feature release?  Shouldn\u0027t it then wait for integrated release ? So do we say that the feature is there in Ironic, but it cannot be used yet.","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0b008dea24f9977de13253e16c953c2cf7a3e2a7","unresolved":false,"context_lines":[{"line_number":79,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":80,"context_line":"  changes should be okay to land in most cases."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"* ??? Anything else?"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Alternatives"},{"line_number":85,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_73574026","line":82,"in_reply_to":"7a016987_8c4aa453","updated":"2015-05-24 15:24:08.000000000","message":"Good questions.\n\n1) I think so, but we can talk more about it. Dmitry had a similar question on patch set 3.\n2) I think we can say that Ironic supports the feature, but Nova does not support it (yet/until next Nova release). No sense in making standalone Ironic installations wait for the next integrated release :)","commit_id":"786380104f8ed14dc7281dcc3e55ed427cab85ef"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5aea160bd3548e800ca670bda882ce5649faef4a","unresolved":false,"context_lines":[{"line_number":11,"context_line":"https://blueprints.launchpad.net/ironic/+spec/feature-based-releases"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"At the Liberty design summit in Vancouver, the Ironic team generally agreed"},{"line_number":14,"context_line":"to move the Ironic project to a feature-based release model.[0] This is an"},{"line_number":15,"context_line":"informational spec to lay out why we are doing this and how it will work."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_a2c42792","line":14,"updated":"2015-06-01 21:40:56.000000000","message":"you\u0027ll add/fix the links to references? :)","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"61047210525944c85de4d8ddfd2cb2b5d7cd1f23","unresolved":false,"context_lines":[{"line_number":11,"context_line":"https://blueprints.launchpad.net/ironic/+spec/feature-based-releases"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"At the Liberty design summit in Vancouver, the Ironic team generally agreed"},{"line_number":14,"context_line":"to move the Ironic project to a feature-based release model.[0] This is an"},{"line_number":15,"context_line":"informational spec to lay out why we are doing this and how it will work."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1af86dd1_a8ad1833","line":14,"in_reply_to":"5afe65bd_073cf2e0","updated":"2015-06-12 15:33:16.000000000","message":"I initially wrote this on a plane and didn\u0027t have internet access to fetch references :)","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"37b3ea3035c531e9684f924547cb5cf3f1e5434a","unresolved":false,"context_lines":[{"line_number":11,"context_line":"https://blueprints.launchpad.net/ironic/+spec/feature-based-releases"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"At the Liberty design summit in Vancouver, the Ironic team generally agreed"},{"line_number":14,"context_line":"to move the Ironic project to a feature-based release model.[0] This is an"},{"line_number":15,"context_line":"informational spec to lay out why we are doing this and how it will work."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_073cf2e0","line":14,"in_reply_to":"5afe65bd_a2c42792","updated":"2015-06-03 03:15:44.000000000","message":"From the point of those who didn\u0027t attend to the summit, the references are essential to understand this spec.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"37b3ea3035c531e9684f924547cb5cf3f1e5434a","unresolved":false,"context_lines":[{"line_number":18,"context_line":"Problem description"},{"line_number":19,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Ironic currently uses the traditional OpenStack release model.[1]"},{"line_number":22,"context_line":"This involves:"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"* One release every six months."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_c726dacd","line":21,"updated":"2015-06-03 03:15:44.000000000","message":"ditto\n\nIs [1] https://wiki.openstack.org/wiki/Release_Cycle ?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"37b3ea3035c531e9684f924547cb5cf3f1e5434a","unresolved":false,"context_lines":[{"line_number":52,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"We should release Ironic (roughly) following the independent release model"},{"line_number":55,"context_line":"defined by the OpenStack governance.[2]"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_c2dc88e6","line":55,"updated":"2015-06-03 03:15:44.000000000","message":"Is [2] https://wiki.openstack.org/wiki/Governance ?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"ac9bf67734e7e0343ace47ce7be8ea1fad811cc5","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the integrated release."}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_041ee4ba","line":60,"updated":"2015-05-29 00:39:21.000000000","message":"Should we address what to do if a major release is not ready?  i.e. we haven\u0027t completed a major feature (\"bitten off more than we can chew\").  We should probably release just bug fixes/small changes, right?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"61047210525944c85de4d8ddfd2cb2b5d7cd1f23","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the integrated release."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1af86dd1_c825f4c2","line":60,"in_reply_to":"5afe65bd_c2b843e8","updated":"2015-06-12 15:33:16.000000000","message":"Michael, correct. Hence the wording \"major features or bug fixes\"\n\nRuby, yes, similar to the client. I don\u0027t think we should really plan releases more than a few weeks out for the reasons you lay out here. Updating this a bit.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5aea160bd3548e800ca670bda882ce5649faef4a","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the integrated release."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_c2b843e8","line":60,"in_reply_to":"7a016987_041ee4ba","updated":"2015-06-01 21:40:56.000000000","message":"Unless major features are developed on a branch, they will be on master -- I am curious to know who decides when to do a release. Will the criteria to do this be similar to the client? Which seems something like \u0027hey devananda, we should push out a new release of the client because ...\u0027 :)\n\nIf we say decide ahead of time, that we\u0027ll do a release when feature X is complete -- I wonder if we\u0027ll have a similar problem; everyone else working on features A,B,C will try to get their feature into the same release as feature X.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"37b3ea3035c531e9684f924547cb5cf3f1e5434a","unresolved":false,"context_lines":[{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the integrated release."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_d6b0cd45","line":62,"updated":"2015-06-03 03:15:44.000000000","message":"Does this mean that the last version of new feature based release just before Feature Freeze of  is merged into the traditional model into the 6 months traditional final release? \n\nMore specifically, in case of Liberty https://wiki.openstack.org/wiki/Liberty_Release_Schedule,\ncan the last version of new feature based release just before Sep. 31st be merged into Liberty Release (2015.2.0) (Oct 15)?\n\nOr is it possible for a new feature based release even after Sep. 31 such as in Release candidates period to be merged into   Liberty Release (2015.2.0) (Oct 15)?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"61047210525944c85de4d8ddfd2cb2b5d7cd1f23","unresolved":false,"context_lines":[{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the integrated release."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1af86dd1_c80cd444","line":62,"in_reply_to":"5afe65bd_d6b0cd45","updated":"2015-06-12 15:33:16.000000000","message":"Yes, this is described in the next bullet point.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"12df6ce693e844a66033a49cee2f0263db001362","unresolved":false,"context_lines":[{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"},{"line_number":66,"context_line":"  \"normal\" Ironic release that happens around the same time that other"},{"line_number":67,"context_line":"  integrated projects begin feature freeze."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":70,"context_line":"  major version for each \"integrated\" release, and the minor version for any"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_224a6e84","line":67,"updated":"2015-06-02 02:44:15.000000000","message":"I think it would be worthwhile to be more explicit about the relationship between this new model and the normal release model. Eg for Liberty [1], we\u0027d use the most recent Ironic release prior/around Sept 31 (Feature Freeze), and the stable/liberty branch will be created at that point in time (THIS IS NEW?), not from the latest stuff on master. (Allowing us to continue development on master).\n\nAnd we\u0027d ignore liberty-1, liberty-2, and no spec/feature proposal freeze, no feature freeze (this is replaced with the \u0027soft freeze\u0027 described below).\n\n[1] https://wiki.openstack.org/wiki/Liberty_Release_Schedule","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"8d4be1975538ab3b733bb176f54978fbbbfdf6e5","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":70,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":71,"context_line":"  releases in between. (What do folks think about this?)"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_931cff6a","line":71,"updated":"2015-05-23 16:52:19.000000000","message":"It\u0027s not a semantic versioning, otherwise LGTM :)","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"ac9bf67734e7e0343ace47ce7be8ea1fad811cc5","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":70,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":71,"context_line":"  releases in between. (What do folks think about this?)"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_44561c5d","line":71,"in_reply_to":"7a016987_1d43e443","updated":"2015-05-29 00:39:21.000000000","message":"I think one blocker against semver here is pbr, which would encourage us down the YYYY.N path since it takes the largest version available.  Should we engage lifeless to see his thoughts on how we can address this?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"b17750e9ed04fd53f0e1098bbfa4f6f4ac838c47","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":70,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":71,"context_line":"  releases in between. (What do folks think about this?)"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_1d43e443","line":71,"in_reply_to":"7a016987_4a8217ca","updated":"2015-05-28 19:18:54.000000000","message":"OpenStack releases are numbered using a YYYY.N time-based scheme so we can\u0027t really follow Semantic Versioning, but I think will be ok. As I see it we could end up with larger N numbers then some other projects but thats Okay I feel.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"0f1622bc79142a2d1d9bdcf0ecbd76ad98d6d7e3","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":70,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":71,"context_line":"  releases in between. (What do folks think about this?)"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":74,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_4a8217ca","line":71,"in_reply_to":"7a016987_931cff6a","updated":"2015-05-26 15:31:52.000000000","message":"It looks good. But I wonder how we can do that, right now in our setup.cfg we have:\n\n version \u003d 2015.2\n\nPerhaps we should flash out in this spec how our versioning system will work in conjunction with the OpenStack one?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"8d4be1975538ab3b733bb176f54978fbbbfdf6e5","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":76,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":77,"context_line":"  as they land."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_73174345","line":77,"updated":"2015-05-23 16:52:19.000000000","message":"Just to clarify: so no more release directories for specs?\nShould we have some deadline before the unfinished spec should be reapproved?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"61047210525944c85de4d8ddfd2cb2b5d7cd1f23","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":76,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":77,"context_line":"  as they land."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1af86dd1_23bf0bd2","line":77,"in_reply_to":"5afe65bd_02e2dbd5","updated":"2015-06-12 15:33:16.000000000","message":"+1","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"ac9bf67734e7e0343ace47ce7be8ea1fad811cc5","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":76,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":77,"context_line":"  as they land."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_a4f4b05a","line":77,"in_reply_to":"7a016987_1dfbe4c2","updated":"2015-05-29 00:39:21.000000000","message":"perhaps just a \"currently approved\" directory, that we might like to review at stable release time? i.e. if a spec is approved, but no real progress has happened, do we push it back to unapproved?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"0f1622bc79142a2d1d9bdcf0ecbd76ad98d6d7e3","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":76,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":77,"context_line":"  as they land."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_c5539b6b","line":77,"in_reply_to":"7a016987_537b24be","updated":"2015-05-26 15:31:52.000000000","message":"I wonder how will that work with launchpad tho, cause there we have to tag specs to a specific release. Perhaps we should just tag the accepted specs to the current release and keep bumping them to the next releases until they are completed.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"a430bc20d6630362f9288a8a812530f7c4f0988d","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":76,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":77,"context_line":"  as they land."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_537b24be","line":77,"in_reply_to":"7a016987_73174345","updated":"2015-05-24 15:16:57.000000000","message":"I\u0027m not sure, let\u0027s talk about it :)","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5aea160bd3548e800ca670bda882ce5649faef4a","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":76,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":77,"context_line":"  as they land."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_02e2dbd5","line":77,"in_reply_to":"7a016987_a4f4b05a","updated":"2015-06-01 21:40:56.000000000","message":"i think we might want:\n- one \u0027approved\u0027 directory, which is where all specs live initially\n- separate \u0027\u003cversion\u003e-implemented\u0027 directories that house the specs that were implemented in \u003cversion\u003e of Ironic\n\nIt means we don\u0027t \u0027unapprove\u0027 specs and reapprove in a new release-to-be -- but it seems to me that this makes sense in the new world. (In fact, I wasn\u0027t quite sure whether it made sense to unapprove specs in our existing world.)","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"b17750e9ed04fd53f0e1098bbfa4f6f4ac838c47","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Specs should be no longer be targeted to a particular release -- folks"},{"line_number":76,"context_line":"  should just work on specs and code continuously. Features will be released"},{"line_number":77,"context_line":"  as they land."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_1dfbe4c2","line":77,"in_reply_to":"7a016987_c5539b6b","updated":"2015-05-28 19:18:54.000000000","message":"not sure about this. Even if it ends up as just a completion \"goal\". I do feel it in still good to target features to a openstack release.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"ac9bf67734e7e0343ace47ce7be8ea1fad811cc5","unresolved":false,"context_lines":[{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"},{"line_number":81,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":82,"context_line":"  changes should be okay to land in most cases."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* ??? Anything else?"},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_c4bd6c69","line":82,"updated":"2015-05-29 00:39:21.000000000","message":"Is this leading up to a stable release, or any release? i.e. are we going to treat all releases the same from a stability POV, or only the ones immediately prior to a stable release for integration with the rest of openstack?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"61047210525944c85de4d8ddfd2cb2b5d7cd1f23","unresolved":false,"context_lines":[{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"},{"line_number":81,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":82,"context_line":"  changes should be okay to land in most cases."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* ??? Anything else?"},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1af86dd1_631d03bd","line":82,"in_reply_to":"5afe65bd_42e213a1","updated":"2015-06-12 15:33:16.000000000","message":"We\u0027ll need to make sure that we communicate these freezes well to cores.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5aea160bd3548e800ca670bda882ce5649faef4a","unresolved":false,"context_lines":[{"line_number":79,"context_line":"* Leading up to a release, reviewers should honor a \"soft freeze\" period of a"},{"line_number":80,"context_line":"  few days to a week. Code that is risky in terms of breakage should probably"},{"line_number":81,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":82,"context_line":"  changes should be okay to land in most cases."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* ??? Anything else?"},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_42e213a1","line":82,"in_reply_to":"7a016987_c4bd6c69","updated":"2015-06-01 21:40:56.000000000","message":"+1. It isn\u0027t clear what release you mean. If any release -- then it means that someone will have apriori decided that a release is upcoming, which means that there will be an attempt for people to try to get their changes in for that release.\n\nI am concerned about these smaller but more frequent \u0027soft freeze\u0027 periods. We don\u0027t do a great job now of communicating, and having to know whether we are in a \u0027soft freeze\u0027 or not (and what is ok to land during this soft freeze) is an extra overhead.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},"change_message_id":"8aa3a341a0ec50dcfb5e3374666582239c044c89","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":82,"context_line":"  changes should be okay to land in most cases."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* ??? Anything else?"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Alternatives"},{"line_number":87,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_0a953f3f","line":84,"updated":"2015-05-26 15:26:48.000000000","message":"Global Dependencies need to be mentioned. See below for example.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"12df6ce693e844a66033a49cee2f0263db001362","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":82,"context_line":"  changes should be okay to land in most cases."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* ??? Anything else?"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"Alternatives"},{"line_number":87,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_42032a10","line":84,"in_reply_to":"7a016987_0a953f3f","updated":"2015-06-02 02:44:15.000000000","message":"Do you mean how/if we will deal with the DepFreeze [1]?\n\n[1] https://wiki.openstack.org/wiki/DepFreeze","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"8d4be1975538ab3b733bb176f54978fbbbfdf6e5","unresolved":false,"context_lines":[{"line_number":106,"context_line":"Client (CLI) impact"},{"line_number":107,"context_line":"-------------------"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"None."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"RPC API impact"},{"line_number":112,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_5329e788","line":109,"updated":"2015-05-23 16:52:19.000000000","message":"Maybe tie client release to the new releases?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"b17750e9ed04fd53f0e1098bbfa4f6f4ac838c47","unresolved":false,"context_lines":[{"line_number":106,"context_line":"Client (CLI) impact"},{"line_number":107,"context_line":"-------------------"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"None."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"RPC API impact"},{"line_number":112,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_dd178cec","line":109,"in_reply_to":"7a016987_5329e788","updated":"2015-05-28 19:18:54.000000000","message":"I think this would be a good idea","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"61047210525944c85de4d8ddfd2cb2b5d7cd1f23","unresolved":false,"context_lines":[{"line_number":106,"context_line":"Client (CLI) impact"},{"line_number":107,"context_line":"-------------------"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"None."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"RPC API impact"},{"line_number":112,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1af86dd1_434a0785","line":109,"in_reply_to":"7a016987_c4644c23","updated":"2015-06-12 15:33:16.000000000","message":"I don\u0027t want to lock us into that by explicitly stating that\u0027s how things should be done, but I\u0027ll mention it.\n\nI don\u0027t want us to get into a habit of saying that only the client released with the server is compatible -- our backwards compatibility should be good enough to not need to do this.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"ac9bf67734e7e0343ace47ce7be8ea1fad811cc5","unresolved":false,"context_lines":[{"line_number":106,"context_line":"Client (CLI) impact"},{"line_number":107,"context_line":"-------------------"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"None."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"RPC API impact"},{"line_number":112,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_c4644c23","line":109,"in_reply_to":"7a016987_dd178cec","updated":"2015-05-29 00:39:21.000000000","message":"+1 I think it\u0027s worthwhile having client/server releases in sync, at least from a compatibility perspective (microversions not withstanding)","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"b17750e9ed04fd53f0e1098bbfa4f6f4ac838c47","unresolved":false,"context_lines":[{"line_number":122,"context_line":"------------------"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"As the Nova driver is released with Nova, it will not change in terms of the"},{"line_number":125,"context_line":"way it is released."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Security impact"},{"line_number":128,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_fd3da82b","line":125,"updated":"2015-05-28 19:18:54.000000000","message":"right now the nova driver does not have a understanding of our micro versioning system. I can see a potential issue once that knowledge is added and nova enters feature freeze. but it shouldn\u0027t be a show stopper.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":8125,"name":"Michael Davies","email":"michael@the-davies.net","username":"mrda"},"change_message_id":"ac9bf67734e7e0343ace47ce7be8ea1fad811cc5","unresolved":false,"context_lines":[{"line_number":122,"context_line":"------------------"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"As the Nova driver is released with Nova, it will not change in terms of the"},{"line_number":125,"context_line":"way it is released."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Security impact"},{"line_number":128,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_8ab1bd03","line":125,"in_reply_to":"7a016987_fd3da82b","updated":"2015-05-29 00:39:21.000000000","message":"I think that\u0027s a separate issue, but one that needs to be addressed.  But just FTR, I\u0027ve raised (https://bugs.launchpad.net/nova/+bug/1459874) to address this.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":9717,"name":"Michael Krotscheck","email":"krotscheck@gmail.com","username":"krotscheck"},"change_message_id":"8aa3a341a0ec50dcfb5e3374666582239c044c89","unresolved":false,"context_lines":[{"line_number":153,"context_line":"Developer impact"},{"line_number":154,"context_line":"----------------"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"All the productivity."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_4aaa1787","line":156,"updated":"2015-05-26 15:26:48.000000000","message":"Ironic will likely have to be decoupled from global requirements, as new feature development during the library freeze may cause slowdowns. \n\nExample: Global Requirements are frozen, dev wants new feature that is in library that\u0027s currently frozen, dev cannot do work.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5aea160bd3548e800ca670bda882ce5649faef4a","unresolved":false,"context_lines":[{"line_number":168,"context_line":"----------"},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"Do it?"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"Dependencies"},{"line_number":174,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_dd40260a","line":171,"updated":"2015-06-01 21:40:56.000000000","message":"Do what? Devil is in the details [1] :-(\n\nProbably want to roll up things from the email discussion.\n\nEg, wrt feature branches for big (beyond frequency of our new feature release model releases) features. How does one decide if a feature goes in a branch or not?\n\n[1] http://lists.openstack.org/pipermail/openstack-dev/2015-May/065036.html","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"b17750e9ed04fd53f0e1098bbfa4f6f4ac838c47","unresolved":false,"context_lines":[{"line_number":179,"context_line":"Testing"},{"line_number":180,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"None."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Upgrades and Backwards Compatibility"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_1d6f642c","line":182,"updated":"2015-05-28 19:18:54.000000000","message":"would there be any impact on out stable branch testing?","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"61047210525944c85de4d8ddfd2cb2b5d7cd1f23","unresolved":false,"context_lines":[{"line_number":179,"context_line":"Testing"},{"line_number":180,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"None."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Upgrades and Backwards Compatibility"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1af86dd1_c734c2df","line":182,"in_reply_to":"7a016987_1d6f642c","updated":"2015-06-12 15:33:16.000000000","message":"Our stable branches will be the integrated releases, so shouldn\u0027t be any impact.","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"8d4be1975538ab3b733bb176f54978fbbbfdf6e5","unresolved":false,"context_lines":[{"line_number":191,"context_line":"Documentation Impact"},{"line_number":192,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Should we document this?"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_332c2b98","line":194,"updated":"2015-05-23 16:52:19.000000000","message":"Definitely","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"a430bc20d6630362f9288a8a812530f7c4f0988d","unresolved":false,"context_lines":[{"line_number":191,"context_line":"Documentation Impact"},{"line_number":192,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Should we document this?"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_334d489a","line":194,"in_reply_to":"7a016987_332c2b98","updated":"2015-05-24 15:16:57.000000000","message":"Yeah, I guess my question was more how/where","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"0f1622bc79142a2d1d9bdcf0ecbd76ad98d6d7e3","unresolved":false,"context_lines":[{"line_number":191,"context_line":"Documentation Impact"},{"line_number":192,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Should we document this?"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_c0126958","line":194,"in_reply_to":"7a016987_334d489a","updated":"2015-05-26 15:31:52.000000000","message":"I think in our docs would be a good spot: http://docs.openstack.org/developer/ironic/dev/contributing.html","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":5805,"name":"Chris Krelle","email":"nobodycam@gmail.com","username":"nobodycam"},"change_message_id":"b17750e9ed04fd53f0e1098bbfa4f6f4ac838c47","unresolved":false,"context_lines":[{"line_number":191,"context_line":"Documentation Impact"},{"line_number":192,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Should we document this?"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a016987_fd6b681c","line":194,"in_reply_to":"7a016987_c0126958","updated":"2015-05-28 19:18:54.000000000","message":"+1","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5aea160bd3548e800ca670bda882ce5649faef4a","unresolved":false,"context_lines":[{"line_number":191,"context_line":"Documentation Impact"},{"line_number":192,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Should we document this?"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_e2433f6b","line":194,"in_reply_to":"7a016987_fd6b681c","updated":"2015-06-01 21:40:56.000000000","message":"I would have said this spec is the documentation but I believe someone made a comment that specs are not documentation.\n\nI think we ought to add a new page in http://docs.openstack.org/developer/ironic/ that describes this release process, with links to OpenStack\u0027s independent release model [2] (which I haven\u0027t read cuz I don\u0027t have the url handy).","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"5aea160bd3548e800ca670bda882ce5649faef4a","unresolved":false,"context_lines":[{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Should we document this?"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"References"},{"line_number":198,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":199,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_bd2a0a2b","line":196,"updated":"2015-06-01 21:40:56.000000000","message":"We should mention how/what/if this model affects i18n/translations (if we ever get lots of translations). Maybe we decide that whatever is translated on master when a release is made, is what goes in. Maybe this makes it easier for translation folks cuz they can translate whenever they want to (or in that soft-freeze period before each release).","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":6618,"name":"Ruby Loo","email":"opensrloo@gmail.com","username":"rloo"},"change_message_id":"12df6ce693e844a66033a49cee2f0263db001362","unresolved":false,"context_lines":[{"line_number":193,"context_line":""},{"line_number":194,"context_line":"Should we document this?"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"References"},{"line_number":198,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":199,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_4d5fdb0e","line":196,"in_reply_to":"5afe65bd_bd2a0a2b","updated":"2015-06-02 02:44:15.000000000","message":"I was referring to how/if we will have a StringFreeze [1]. I suppose we do have a string freeze -- the strings are frozen on stable/, which was generated off of master at the point of our most recent release. It means the i18n folks will need to look at the stable branch, not master, for doing the translations? (and we\u0027d have to sync/cherry-pick? the changes between master and stable branch???)\n\n[1] https://wiki.openstack.org/wiki/StringFreeze","commit_id":"cead6b031fdb44671cb0e48ad6c45ec4f789c1de"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"c831fc4594a87394e7ef23ca349068c19401cd11","unresolved":false,"context_lines":[{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the integrated release.[3]"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"},{"line_number":66,"context_line":"  \"normal\" Ironic release that happens around the same time that other"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1af86dd1_86aa436f","line":63,"updated":"2015-06-12 19:23:42.000000000","message":"It\u0027s now called the \"coordinated release\" now. The \"integrated release\" is going to be dissolved this cycle.","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0d0e5e3a5dce9c3dff7f4eb169b41c735fa0f73d","unresolved":false,"context_lines":[{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the integrated release.[3]"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"},{"line_number":66,"context_line":"  \"normal\" Ironic release that happens around the same time that other"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_5ddbec1b","line":63,"in_reply_to":"1af86dd1_86aa436f","updated":"2015-06-13 14:58:27.000000000","message":"Thanks.","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"09779d9ac97e22d301b9e93d59e971e822de9256","unresolved":false,"context_lines":[{"line_number":70,"context_line":"  be built from this branch and may receive bug fixes. Stable releases should"},{"line_number":71,"context_line":"  be eligible for receiving backports following the current process."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":74,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":75,"context_line":"  releases in between. Other projects are switching to semver anyway[5], so"},{"line_number":76,"context_line":"  I don\u0027t expect any major problems with doing this."}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_0205ffc0","line":73,"updated":"2015-06-13 12:05:32.000000000","message":"Actually, I think we should bump the major version for each feature release we make, not just the ones which happen to coincide with OpenStack coordinated releases.\n\nWe should also bump the minor or patch versions as necessary for intermediate releases and bug fix releases, following SemVer.","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"9657011a4390fd099fac10040c239774f35ce0e7","unresolved":false,"context_lines":[{"line_number":70,"context_line":"  be built from this branch and may receive bug fixes. Stable releases should"},{"line_number":71,"context_line":"  be eligible for receiving backports following the current process."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":74,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":75,"context_line":"  releases in between. Other projects are switching to semver anyway[5], so"},{"line_number":76,"context_line":"  I don\u0027t expect any major problems with doing this."}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_e2b81be8","line":73,"in_reply_to":"fa32b979_0205ffc0","updated":"2015-06-13 12:10:24.000000000","message":"+1","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0d0e5e3a5dce9c3dff7f4eb169b41c735fa0f73d","unresolved":false,"context_lines":[{"line_number":70,"context_line":"  be built from this branch and may receive bug fixes. Stable releases should"},{"line_number":71,"context_line":"  be eligible for receiving backports following the current process."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":74,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":75,"context_line":"  releases in between. Other projects are switching to semver anyway[5], so"},{"line_number":76,"context_line":"  I don\u0027t expect any major problems with doing this."}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_bdceb858","line":73,"in_reply_to":"fa32b979_e2b81be8","updated":"2015-06-13 14:58:27.000000000","message":"Agree. We had some consensus on this model at the summit, so was capturing that here. I\u0027d also prefer real semver. :)","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"c831fc4594a87394e7ef23ca349068c19401cd11","unresolved":false,"context_lines":[{"line_number":73,"context_line":"* Ironic releases should roughly follow semantic versioning -- bumping the"},{"line_number":74,"context_line":"  major version for each \"integrated\" release, and the minor version for any"},{"line_number":75,"context_line":"  releases in between. Other projects are switching to semver anyway[5], so"},{"line_number":76,"context_line":"  I don\u0027t expect any major problems with doing this."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"1af86dd1_a649bfd2","line":76,"updated":"2015-06-12 19:23:42.000000000","message":"Are there no contingencies under which a patch release would be made in the middle of a cycle? It might be better to just say that you\u0027ll follow SemVer, rather than \"roughly\".","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"c831fc4594a87394e7ef23ca349068c19401cd11","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"We should investigate releasing server and client versions at the same time."},{"line_number":130,"context_line":"However, regardless of if this is done, we should support older clients with"},{"line_number":131,"context_line":"new servers and vice versa."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"RPC API impact"},{"line_number":134,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1af86dd1_065f7373","line":131,"updated":"2015-06-12 19:23:42.000000000","message":"Library releases, including clients, are likely to happen much more often than the server. I intend to review pending changes weekly, for example.","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"09779d9ac97e22d301b9e93d59e971e822de9256","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"We should investigate releasing server and client versions at the same time."},{"line_number":130,"context_line":"However, regardless of if this is done, we should support older clients with"},{"line_number":131,"context_line":"new servers and vice versa."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"RPC API impact"},{"line_number":134,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_223123a3","line":131,"in_reply_to":"1af86dd1_065f7373","updated":"2015-06-13 12:05:32.000000000","message":"The client can have support for unreleased (but landed in trunk) features and should handle the version negotiation just fine.\n\nIn practice, I suspect that we\u0027ll end up releasing the client more often and shortly ahead of feature releases of the server. But I don\u0027t think they should be coupled, and I don\u0027t think we should include wording to the encourage that assumption.","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0d0e5e3a5dce9c3dff7f4eb169b41c735fa0f73d","unresolved":false,"context_lines":[{"line_number":128,"context_line":""},{"line_number":129,"context_line":"We should investigate releasing server and client versions at the same time."},{"line_number":130,"context_line":"However, regardless of if this is done, we should support older clients with"},{"line_number":131,"context_line":"new servers and vice versa."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"RPC API impact"},{"line_number":134,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_fd02006f","line":131,"in_reply_to":"fa32b979_223123a3","updated":"2015-06-13 14:58:27.000000000","message":"Okay, folks were asking about doing this so I added this. I\u0027ll remove it.","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"09779d9ac97e22d301b9e93d59e971e822de9256","unresolved":false,"context_lines":[{"line_number":150,"context_line":"---------------"},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"As only stable releases will receive backports, security bugs in other releases"},{"line_number":153,"context_line":"should be fixed and released ASAP. An advisory should be published that"},{"line_number":154,"context_line":"encourages users to upgrade to the new release."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Stable branches should continue to receive backports for security bug fixes."}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_02d3bf39","line":153,"updated":"2015-06-13 12:05:32.000000000","message":"\"security bugs in other releases...\" -- can you be more explicit by what you mean with \"other releases\"?\n\nIf I\u0027m interpreting this correctly, it\u0027s not what Doug and Thierry and I discussed in YVR (that being, only stable releases receive backports).","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0d0e5e3a5dce9c3dff7f4eb169b41c735fa0f73d","unresolved":false,"context_lines":[{"line_number":150,"context_line":"---------------"},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"As only stable releases will receive backports, security bugs in other releases"},{"line_number":153,"context_line":"should be fixed and released ASAP. An advisory should be published that"},{"line_number":154,"context_line":"encourages users to upgrade to the new release."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Stable branches should continue to receive backports for security bug fixes."}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_9df8947e","line":153,"in_reply_to":"fa32b979_02d3bf39","updated":"2015-06-13 14:58:27.000000000","message":"\"Other than stable\". I\u0027ll improve the wording here.","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"9657011a4390fd099fac10040c239774f35ce0e7","unresolved":false,"context_lines":[{"line_number":179,"context_line":"Developer impact"},{"line_number":180,"context_line":"----------------"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"All the productivity."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_02badfe1","line":182,"updated":"2015-06-13 12:10:24.000000000","message":"Upstream, I can see this adding to productivity, but Have we pondered downstream developer/packager impact of this?","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"0d0e5e3a5dce9c3dff7f4eb169b41c735fa0f73d","unresolved":false,"context_lines":[{"line_number":179,"context_line":"Developer impact"},{"line_number":180,"context_line":"----------------"},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"All the productivity."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fa32b979_3d306856","line":182,"in_reply_to":"fa32b979_02badfe1","updated":"2015-06-13 14:58:27.000000000","message":"Packagers have said they will still follow the 6-month releases as they need long-term supported branches.\n\nI\u0027m not sure about downstream developers; I don\u0027t think this really affects them much unless they\u0027re only developing on released versions?","commit_id":"9011583671aa63755361681b01c2c017bce0ed81"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"6a4a88f0fabd688dc559d5a44f4204eb3ea41d18","unresolved":false,"context_lines":[{"line_number":26,"context_line":"* A feature freeze prior to cutting this release, typically for a duration"},{"line_number":27,"context_line":"  of six weeks. Only bug fix work and docs work should be done in this period."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"* A spec freeze a few weeks prior to the feature freeze."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"* After the feature freeze period, a stable branch is forked from master and a"},{"line_number":32,"context_line":"  release candidate period begins. Critical bugs fixed on master during this"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_8f449db7","line":29,"updated":"2015-06-22 12:39:12.000000000","message":"This is optional.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"21b46bc0c2720becb2c10a212552a5939bc2902c","unresolved":false,"context_lines":[{"line_number":26,"context_line":"* A feature freeze prior to cutting this release, typically for a duration"},{"line_number":27,"context_line":"  of six weeks. Only bug fix work and docs work should be done in this period."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"* A spec freeze a few weeks prior to the feature freeze."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"* After the feature freeze period, a stable branch is forked from master and a"},{"line_number":32,"context_line":"  release candidate period begins. Critical bugs fixed on master during this"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_861a3f16","line":29,"in_reply_to":"fa32b979_8f449db7","updated":"2015-06-22 14:48:13.000000000","message":"Oh, good to know :)","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"6a4a88f0fabd688dc559d5a44f4204eb3ea41d18","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"* After about four weeks of iterating on release candidates, the final version"},{"line_number":36,"context_line":"  is released. This stable release may receive critical bug fixes for a longer"},{"line_number":37,"context_line":"  period of 12-18 months."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"This model creates a few problems. The primary problem created is that"},{"line_number":40,"context_line":"development happens in peaks and valleys. Developers and vendors realize that"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_af3f2124","line":37,"updated":"2015-06-22 12:39:12.000000000","message":"More like 9-15 months those days.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"21b46bc0c2720becb2c10a212552a5939bc2902c","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"* After about four weeks of iterating on release candidates, the final version"},{"line_number":36,"context_line":"  is released. This stable release may receive critical bug fixes for a longer"},{"line_number":37,"context_line":"  period of 12-18 months."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"This model creates a few problems. The primary problem created is that"},{"line_number":40,"context_line":"development happens in peaks and valleys. Developers and vendors realize that"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_e61b0b1b","line":37,"in_reply_to":"fa32b979_af3f2124","updated":"2015-06-22 14:48:13.000000000","message":"Thanks","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"91df8ac27ce812effdc4150230a05c2a24024928","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_7708042e","line":60,"updated":"2015-06-16 07:08:23.000000000","message":"I agree that Ironic\u0027s PTL can make the final decision.\n\nHowever I think we need to clarify how to decide what features should be completed on the master branch in what priority or order.\n\nThis process is not visible in the current model especially from vendors which don\u0027t have core member.\n\nIf we don\u0027t have any words rather than just saying \"whatever we land\" regarding feature priority [1], we need to clarify it in rational and logical manner so that every contributor can understand. \n\nI think each vendor or contributor should have a formal opportunity to discuss and agree what are major features of each features release so that every  vendor or contributor can get treated fairly.\n\nTherefor I propose to define a step as a standard procedure to agree upon each major feature\u0027s priority among cores and non core contributors.\n\nWhat do you think?\n\n[1] http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-06-15-17.02.html\n\nBest regards,\n\nNaohiro","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"442c169079499031ec2ce11486e457993b18c70b","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_1848ab2c","line":60,"updated":"2015-06-16 16:32:26.000000000","message":"What do you mean by \"should be complete\"? Again and again, we can\u0027t force anyone here. The only thing we do is we set a project-wide priorities, and try to follow them. But we can\u0027t force anyone to follow even these priorities.\n\nThe only way for \"vendor or contributor\" to affect _anything_ in a FOSS project is to make more contributions.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"496f7af2b0ecf4a69524f54de797becbb5e2d3e7","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_834f516a","line":60,"in_reply_to":"fa32b979_1848ab2c","updated":"2015-06-17 05:45:04.000000000","message":"Dmitry,\n\nI got your point. thanks.\n\nI understood that  \"should be complete\" is not right words.\nThere was my implicit premise that all vendor or contributor can develop their feature by the deadline.\n\nI\u0027d like to alter the sentence as follows:\n\n [before] However I think we need to clarify how to decide what features should be completed on the master branch in what priority or order.\n\n [after]  However I think we need to clarify how to decide what features *can be merged* on the master branch in what priority or order.\n\nBest regards,\n\nNaohiro","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"21b46bc0c2720becb2c10a212552a5939bc2902c","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_78511ed8","line":60,"in_reply_to":"fa32b979_6adb927c","updated":"2015-06-22 14:48:13.000000000","message":"I personally am opposed to that. Like Dmitry said, we can\u0027t force folks to complete a feature, we can\u0027t force folks to review certain things. I don\u0027t think locking features to a given release is a good model for us.\n\nWe *do* need to get better at deciding and tracking priorities, as a project. This is something we don\u0027t do well.\n\nI\u0027d like Deva\u0027s take on this thread.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d96b277b9290179ec76e5472c30b6c49df181070","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_ec76703d","line":60,"in_reply_to":"fa32b979_6adb927c","updated":"2015-06-23 05:08:22.000000000","message":"Naohiro said:\n\u003e So can we put a following one sentence in this document?\n\u003e \"\"\" Ironic team holds a meeting which invites openly \n\u003e all contributors including cores and non cores to \n\u003e decide what features make a release. \"\"\"\n\nNo, we can\u0027t. Ironic\u0027s features are not \"decided\" by a committee of all vendors\u0027 representatives including non-cores, who are not responsible for reviewing code or maintaning quality of the software. Also, that\u0027s not what this proposal is about; changing our release model is orthogonal to changing how we decide what features to implement when.\n\ntldr; there is no way I can commit publicly and say \"future release #123 will have feature A from vendor X, and feature B from vendor Y\". Even if I wrote one of those features myself, it needs peer review, and anyway, I can\u0027t guarantee that will happen at the same time as some other feature.\n\nWe can, however, discuss the things each of us want to work on, roughly prioritize the review queue, and then release when some work is completed, and document what was included in that release. And this is, in fact, what the core team does today :)","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"79bab38376e274cc63599bf9d86a6376076debba","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_6adb927c","line":60,"in_reply_to":"fa32b979_6e988d78","updated":"2015-06-19 06:51:48.000000000","message":"Jim,\n \u003e\u003e [after]  However I think we need to clarify how to decide what features *can be merged* on the master branch in what priority or order.\n \u003e\u003e\n \u003e One of the problems we want to solve with this is vendors begging for reviews\n \u003e on a feature so that it can sneak in before a release. \n \u003e Having a meeting to decide what features make a release kind of defeats that.\n\nThat\u0027s exactly what I proposed, and trying to say. Thanks :)\n\nIf some vendor could sneak in, it\u0027s really unfair for other vendors.\nCurrently the process of deciding features of release or priority of features is not openly defined or standardized in Ironic, that makes some vender try to sneak.\n\nHowever once we created a step, \"Having a meeting to decide what features make a release kind of defeats that.\", as a Ironic standard, we can play and compete fairly. Sneaking becomes impossible.\n\nSo can we put a following one sentence in this document?\n\n\"\"\"\nIronic team holds a meeting which invites openly all contributors including cores and non cores to decide what features make a release.\n\"\"\"\n\nBest regards,\n\nNaohiro","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"3e548b99a0e67286b47b769d8c1d491a1ead9e3e","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_f372d310","line":60,"in_reply_to":"fa32b979_78511ed8","updated":"2015-06-23 02:34:51.000000000","message":"Devananda, Jim, Dmitry,\n\nI don\u0027t have any objection that we cannot force folks to complete a\nfeature, we can\u0027t force folks to review certain things.\n\nI personally think that everything should be conducted based on our\nagreement.\n\nI think there are two cases, and the case 2 is the matter we need an\nagreement.\n\ncase 1)\n Contributor\u0027s code is not ready, I agree with you that we cannot\n force the contributor to meet certain deadline.\n In this case, an agreement can be made easily, because the\n contributor doesn\u0027t want to merge, and community doesn\u0027t let the\n feature merge because of its quality.\n       \ncase2)\n Contributor\u0027s code is ready, and eager to merge.\n However contributor\u0027s feature is set to low priority, blocked to\n review, and bumped from a release due to undisclosed reason or\n process.\n\nMy proposal doesn\u0027t force anything to anyone, it\u0027s totally up to each\nindividual how to act and react.\n\nHowever we need certain rule and standard to work together.\nMy proposal is in order to make agreement how to solve the case 2.\nI think \"force\" begins with a lack of presenting reasonable reason.\nIf reasonable reason is presented and agreement is made, I believe\nthat nobody says it\u0027s \"force\".\n\nBest regards,\n\nNaohiro","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"92fcdf1533abf8459af088b4e4116259f69582f8","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_6e988d78","line":60,"in_reply_to":"fa32b979_834f516a","updated":"2015-06-18 23:56:40.000000000","message":"This spec has nothing to do with how the team decides project priorities, nor how we decide what to review. That\u0027s completely out of scope for this spec.\n\nOne of the problems we want to solve with this is vendors begging for reviews on a feature so that it can sneak in before a release. Having a meeting to decide what features make a release kind of defeats that.\n\nI also never want to be in a situation where we\u0027re blocking a release for any feature.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"1ef5c4aaed87274f88901eae9b33cc915522f199","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_f0d633c2","line":60,"in_reply_to":"fa32b979_ec76703d","updated":"2015-06-23 12:24:27.000000000","message":"Jim, \tDevananda,\n\nOkay, I understood.\nThank you for the detailed explanation and sparing your time for me in the Ironic IRC meeting and Ironic IRC channel :-)\n\nBest regards,\n\nNaohiro","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"fd375fed8c409a27ed44f2f3dfe4561093f190f3","unresolved":false,"context_lines":[{"line_number":57,"context_line":"There are a few things of note here."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_16272513","line":60,"in_reply_to":"fa32b979_f372d310","updated":"2015-06-23 03:27:15.000000000","message":"To be clear, I *do* think we should communicate priorities better. We aren\u0027t good at that. We need to get better.\n\nHowever, I do think that is out of scope for the spec and for the release process. The goal here is for making a new Ironic release to be a very lightweight process; someone decides to release, pushes a tag, and says \"it is done\". I think that deciding features before the release, and evaluating if all of those features are complete, what to bump, etc prior to doing a release, is the antithesis of this model.\n\nWe should definitely continue this conversation, but outside of this spec.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"6a4a88f0fabd688dc559d5a44f4204eb3ea41d18","unresolved":false,"context_lines":[{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_ef6c490a","line":62,"updated":"2015-06-22 12:39:12.000000000","message":"I\u0027d say \u003c\u003ca \"final\" release at the end of the 6-month development cycle, to continue to be part of the coordinated release and corresponding stable branch.\u003e\u003e","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"21b46bc0c2720becb2c10a212552a5939bc2902c","unresolved":false,"context_lines":[{"line_number":59,"context_line":"* We should release Ironic when major features or bug fixes are complete on"},{"line_number":60,"context_line":"  the master branch. This will be at the discretion of Ironic\u0027s PTL."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* We should continue to release a \"stable\" release every six months,"},{"line_number":63,"context_line":"  to continue to be part of the coordinated release.[3]"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_06262f68","line":62,"in_reply_to":"fa32b979_ef6c490a","updated":"2015-06-22 14:48:13.000000000","message":"Thanks","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"6a4a88f0fabd688dc559d5a44f4204eb3ea41d18","unresolved":false,"context_lines":[{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"},{"line_number":66,"context_line":"  \"normal\" Ironic release that happens around the same time that other"},{"line_number":67,"context_line":"  integrated projects begin feature freeze. For example, for Liberty[4],"},{"line_number":68,"context_line":"  Ironic should make a release in the first week of September. This will"},{"line_number":69,"context_line":"  become equivalent to the stable/liberty branch. Release candidates should"},{"line_number":70,"context_line":"  be built from this branch and may receive bug fixes. Stable releases should"},{"line_number":71,"context_line":"  be eligible for receiving backports following the current process."}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_cf2065b3","line":68,"updated":"2015-06-22 12:39:12.000000000","message":"I think you can target the second half of September, which is when other projects would release their RC1. Releasing more often should mean you distribute bug fixing more evenly across the cycle, so you should not need MORE time between your RC and final than the others :)","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"21b46bc0c2720becb2c10a212552a5939bc2902c","unresolved":false,"context_lines":[{"line_number":65,"context_line":"* In lieu of a feature freeze, Ironic\u0027s \"stable\" release should come from a"},{"line_number":66,"context_line":"  \"normal\" Ironic release that happens around the same time that other"},{"line_number":67,"context_line":"  integrated projects begin feature freeze. For example, for Liberty[4],"},{"line_number":68,"context_line":"  Ironic should make a release in the first week of September. This will"},{"line_number":69,"context_line":"  become equivalent to the stable/liberty branch. Release candidates should"},{"line_number":70,"context_line":"  be built from this branch and may receive bug fixes. Stable releases should"},{"line_number":71,"context_line":"  be eligible for receiving backports following the current process."}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_662ffb3e","line":68,"in_reply_to":"fa32b979_cf2065b3","updated":"2015-06-22 14:48:13.000000000","message":"Good point :)","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"6a9161f8498799c403f229b4ae6507a36e6fca16","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should follow SemVer[5]-- bumping the major version for each"},{"line_number":74,"context_line":"  feature release, and minor or patch versions for intermediate and bug fix"},{"line_number":75,"context_line":"  releases."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_33797794","line":75,"updated":"2015-06-13 17:33:54.000000000","message":"SemVer versions have 3 values major.minor.patch, and each indicates a different type of change. Patches are bug fixes, and the minor number indicates a compatible release with new features. Major version increases are really meant to signal incompatibilities. So it makes sense to raise the major version when you, for example, make backwards-incompatible API changes, collapse the schema migrations into one script, or do something else that means that the previous major version series and the next-to-be-released version are not compatible in some way.\n\nWe\u0027ve talked about raising the major version number on the 6 month cycle as a way to indicate which series has stable support, as well. So if you release 4.0.0 (around L1) followed by 4.0.1 (with a bug fix) then 4.1.0 (with a major new feature) before the end of Liberty, we might create the stable/M branch at 4.1.0 (or even 4.1.n where n!\u003d0) and the next release would be 5.0.0.\n\nWhat you\u0027re proposing sounds more like swift\u0027s \"marketing influenced semver\", which uses that major version number to signal a big feature release, and that\u0027s not really what we want everyone doing because that makes it more difficult for deployers to figure out how big of a deal any given release actually is in terms of upgrade costs.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"e265e85aae14858abf174305b97272ce70905efc","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should follow SemVer[5]-- bumping the major version for each"},{"line_number":74,"context_line":"  feature release, and minor or patch versions for intermediate and bug fix"},{"line_number":75,"context_line":"  releases."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_55963c4d","line":75,"in_reply_to":"fa32b979_33797794","updated":"2015-06-15 14:02:49.000000000","message":"I don\u0027t really see us doing many breaking updates. I\u0027d like to hear Deva\u0027s opinion on it.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"10c03b5ba28a37d00380adc0f47a4cbada2b0449","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should follow SemVer[5]-- bumping the major version for each"},{"line_number":74,"context_line":"  feature release, and minor or patch versions for intermediate and bug fix"},{"line_number":75,"context_line":"  releases."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_c0ee088b","line":75,"in_reply_to":"fa32b979_55963c4d","updated":"2015-06-15 14:23:55.000000000","message":"The frequency of breaking changes isn\u0027t really important, per se. It is more important to be consistent with signaling the nature of changes between releases by sticking to the same semver rules the other projects will be using as closely as possible.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d96b277b9290179ec76e5472c30b6c49df181070","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"* Ironic releases should follow SemVer[5]-- bumping the major version for each"},{"line_number":74,"context_line":"  feature release, and minor or patch versions for intermediate and bug fix"},{"line_number":75,"context_line":"  releases."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_326127a9","line":75,"in_reply_to":"fa32b979_c0ee088b","updated":"2015-06-23 05:08:22.000000000","message":"I do not agree that the project\u0027s released version number either needs to coincide with the release numbering for the majority of other OpenStack projects, nor that it needs to be bumped for every release.\n\nI also don\u0027t feel that the major version needs to be bumped with every new feature. That\u0027s what API version numbering is for...\n\nWhen there is a \"significant\" change in the project functionality or code, then major bump. When there\u0027s a new release that adds a feature, minor bump. Release fixing bugs, patch version.\n\nWe should never do a release that has no upgrade path from a prior release -- if we do that, we might as well call it a different piece of software because we\u0027ve just abandoned our users.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"6a9161f8498799c403f229b4ae6507a36e6fca16","unresolved":false,"context_lines":[{"line_number":95,"context_line":"  During OpenStack\u0027s feature freeze, the master branch of global-requirements"},{"line_number":96,"context_line":"  is locked. It should be okay to accept changes to Ironic\u0027s requirements.txt"},{"line_number":97,"context_line":"  on the master branch that are blocked in global-requirements by the Dep"},{"line_number":98,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_f3722fad","line":98,"updated":"2015-06-13 17:33:54.000000000","message":"I\u0027m not sure this is a good idea. Are you anticipating needing to update the requirements early?","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"ddb5ac075aee3b0d078daca28fc2f5a30527fad9","unresolved":false,"context_lines":[{"line_number":95,"context_line":"  During OpenStack\u0027s feature freeze, the master branch of global-requirements"},{"line_number":96,"context_line":"  is locked. It should be okay to accept changes to Ironic\u0027s requirements.txt"},{"line_number":97,"context_line":"  on the master branch that are blocked in global-requirements by the Dep"},{"line_number":98,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_e1946e38","line":98,"in_reply_to":"fa32b979_406e7830","updated":"2015-06-15 15:04:34.000000000","message":"Yeah, I think the wording is bad here. My goal with this bullet point is to point out the problem and how we may work around it. I\u0027ll try to clear it up in the next patchset.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"10c03b5ba28a37d00380adc0f47a4cbada2b0449","unresolved":false,"context_lines":[{"line_number":95,"context_line":"  During OpenStack\u0027s feature freeze, the master branch of global-requirements"},{"line_number":96,"context_line":"  is locked. It should be okay to accept changes to Ironic\u0027s requirements.txt"},{"line_number":97,"context_line":"  on the master branch that are blocked in global-requirements by the Dep"},{"line_number":98,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_406e7830","line":98,"in_reply_to":"fa32b979_d5a1ecaa","updated":"2015-06-15 14:23:55.000000000","message":"Right, I understood that. What I meant was, do you think this is going to be so common that the default will be to decouple from the global requirements each cycle, or are you including this as a contingency? Because doing it every cycle is likely to introduce issues so I would really prefer that we take it on a case-by-case basis until we iron out the other issues with intermediate releases.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"d96b277b9290179ec76e5472c30b6c49df181070","unresolved":false,"context_lines":[{"line_number":95,"context_line":"  During OpenStack\u0027s feature freeze, the master branch of global-requirements"},{"line_number":96,"context_line":"  is locked. It should be okay to accept changes to Ironic\u0027s requirements.txt"},{"line_number":97,"context_line":"  on the master branch that are blocked in global-requirements by the Dep"},{"line_number":98,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_72ec8ff3","line":98,"in_reply_to":"fa32b979_e1946e38","updated":"2015-06-23 05:08:22.000000000","message":"I agree with Jim\u0027s point -- this is a potential source of developer friction. We haven\u0027t hit it yet, but it seems likely. As long as ironic/master:requirements.txt is pinned by Dep Freeze, developers *might* run into a problem if they\u0027re adding/updating things during the global freeze window.\n\nI\u0027d like to have a contingency plan; simply saying \"you need to wait 6 weeks to land this\" isn\u0027t great.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"e265e85aae14858abf174305b97272ce70905efc","unresolved":false,"context_lines":[{"line_number":95,"context_line":"  During OpenStack\u0027s feature freeze, the master branch of global-requirements"},{"line_number":96,"context_line":"  is locked. It should be okay to accept changes to Ironic\u0027s requirements.txt"},{"line_number":97,"context_line":"  on the master branch that are blocked in global-requirements by the Dep"},{"line_number":98,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_d5a1ecaa","line":98,"in_reply_to":"fa32b979_f3722fad","updated":"2015-06-15 14:02:49.000000000","message":"So what I\u0027m thinking here:\n\nAt this point we\u0027ve already cut a stable branch for the coordinated release, and global-reqs is frozen. A developer needs a new or updated library on master.\n\nIf that developer gets a \"LGTM but -2 because freeze\" review on a global-reqs patch, the corresponding patch to requirements.txt in ironic may be merged.\n\nDoes that make more sense?","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"442c169079499031ec2ce11486e457993b18c70b","unresolved":false,"context_lines":[{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"},{"line_number":102,"context_line":"  necessary as feature branches can carry a large amount of pain. We should"},{"line_number":103,"context_line":"  prefer feature flags over feature branches where possible."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Alternatives"},{"line_number":106,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_b8565fd0","line":103,"updated":"2015-06-16 16:32:26.000000000","message":"+1 to question","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"91df8ac27ce812effdc4150230a05c2a24024928","unresolved":false,"context_lines":[{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"},{"line_number":102,"context_line":"  necessary as feature branches can carry a large amount of pain. We should"},{"line_number":103,"context_line":"  prefer feature flags over feature branches where possible."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Alternatives"},{"line_number":106,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_2277983b","line":103,"updated":"2015-06-16 07:08:23.000000000","message":"just a question. \n\nwhat is \"feature flags\"?\nIs it a one of git function?\nI coudn\u0027t find anything about \"git flags\" by google search.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":13719,"name":"Naohiro Tamura","email":"naohirot.openstack@gmail.com","username":"nao"},"change_message_id":"79bab38376e274cc63599bf9d86a6376076debba","unresolved":false,"context_lines":[{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"},{"line_number":102,"context_line":"  necessary as feature branches can carry a large amount of pain. We should"},{"line_number":103,"context_line":"  prefer feature flags over feature branches where possible."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Alternatives"},{"line_number":106,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_e5527312","line":103,"in_reply_to":"fa32b979_2e75a530","updated":"2015-06-19 06:51:48.000000000","message":"Thanks, I\u0027ll take a look.\n\nIt would be helpful to put a reference url you recommend to readers if there is.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"92fcdf1533abf8459af088b4e4116259f69582f8","unresolved":false,"context_lines":[{"line_number":100,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":101,"context_line":"  these can be useful, we must be sure to only use them when absolutely"},{"line_number":102,"context_line":"  necessary as feature branches can carry a large amount of pain. We should"},{"line_number":103,"context_line":"  prefer feature flags over feature branches where possible."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Alternatives"},{"line_number":106,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_2e75a530","line":103,"in_reply_to":"fa32b979_b8565fd0","updated":"2015-06-18 23:56:40.000000000","message":"A feature flag is a way for a deployer or operator to enable a feature. This may be a config option, a database field, etc. It\u0027s a fairly common term; if you google \"feature flag\" you\u0027ll find many writings about it.\n\nSo if you have a feature in development, you can guard around using it with the flag, and turn it on when done.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"6a9161f8498799c403f229b4ae6507a36e6fca16","unresolved":false,"context_lines":[{"line_number":157,"context_line":"security bug in an intermediate release should be fixed and released with"},{"line_number":158,"context_line":"the appropriate version bump. Whether the version change is major/minor/patch"},{"line_number":159,"context_line":"may depend on what else has landed on master and will be released with the"},{"line_number":160,"context_line":"patch."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Other end user impact"},{"line_number":163,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_b39347a3","line":160,"updated":"2015-06-13 17:33:54.000000000","message":"Do you want to mention here that the fixes still may be backported to the previous stable release?","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"10c03b5ba28a37d00380adc0f47a4cbada2b0449","unresolved":false,"context_lines":[{"line_number":157,"context_line":"security bug in an intermediate release should be fixed and released with"},{"line_number":158,"context_line":"the appropriate version bump. Whether the version change is major/minor/patch"},{"line_number":159,"context_line":"may depend on what else has landed on master and will be released with the"},{"line_number":160,"context_line":"patch."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Other end user impact"},{"line_number":163,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_408af8c0","line":160,"in_reply_to":"fa32b979_15a0b49e","updated":"2015-06-15 14:23:55.000000000","message":"Yep, totally skipped over that. :-)","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"e265e85aae14858abf174305b97272ce70905efc","unresolved":false,"context_lines":[{"line_number":157,"context_line":"security bug in an intermediate release should be fixed and released with"},{"line_number":158,"context_line":"the appropriate version bump. Whether the version change is major/minor/patch"},{"line_number":159,"context_line":"may depend on what else has landed on master and will be released with the"},{"line_number":160,"context_line":"patch."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Other end user impact"},{"line_number":163,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"fa32b979_15a0b49e","line":160,"in_reply_to":"fa32b979_b39347a3","updated":"2015-06-15 14:02:49.000000000","message":"See \"Stable branches should continue to receive backports for security bug fixes.\" above this paragraph.","commit_id":"bd497c283d6e1f3cb5b2cb4a53c0f81d1797064e"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1f35903f598e9a96cba335a50de07d2cc97ae6c8","unresolved":false,"context_lines":[{"line_number":101,"context_line":"  on the master branch that are blocked in global-requirements by the Dep"},{"line_number":102,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":103,"context_line":"  This should only happen on an as-needed basis as the problem arises; not"},{"line_number":104,"context_line":"  by default."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":107,"context_line":"  these can be useful, we must be sure to only use them when absolutely"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba3cc151_7c4a5d85","line":104,"updated":"2015-06-29 17:46:20.000000000","message":"Right we will need to disable gate-ironic-requirements for that, any patches to requirements.txt in Ironic tree that is different than openstack/requirements will cause the gate to fail (e.g https://review.openstack.org/#/c/196010/)\n\n\"gate-ironic-requirements http://logs.openstack.org/10/196010/1/check/gate-ironic-requirements/68a3886/ : Incompatible requirement found; see https://wiki.openstack.org/wiki/Requirements in 16s\"\n\n...\n\nAlso I remember we talked about it before and you mentioned that in order to avoid diverging from global-requirements we would need at least a patch in the openstack/requirements with \"LGTM but we are currently in freeze\" message so we know the directions to add that dependency is fine.\n\nShould we expand this a little to mention it?","commit_id":"1d15e84b7844a49b9cdd473b76f654f096609a97"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1f35903f598e9a96cba335a50de07d2cc97ae6c8","unresolved":false,"context_lines":[{"line_number":106,"context_line":"* Folks have discussed using feature branches for larger chunks of work. While"},{"line_number":107,"context_line":"  these can be useful, we must be sure to only use them when absolutely"},{"line_number":108,"context_line":"  necessary as feature branches can carry a large amount of pain. We should"},{"line_number":109,"context_line":"  prefer feature flags over feature branches where possible."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Alternatives"},{"line_number":112,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba3cc151_3c0cd593","line":109,"updated":"2015-06-29 17:46:20.000000000","message":"nit: add a reference about feature flag\n\n\"... feature flags [9] ...\"\n\n( I had to google to figure what feature flag means)","commit_id":"1d15e84b7844a49b9cdd473b76f654f096609a97"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"1f35903f598e9a96cba335a50de07d2cc97ae6c8","unresolved":false,"context_lines":[{"line_number":246,"context_line":"[5] http://semver.org/"},{"line_number":247,"context_line":"[6] http://lists.openstack.org/pipermail/openstack-dev/2015-May/065211.html"},{"line_number":248,"context_line":"[7] https://wiki.openstack.org/wiki/DepFreeze"},{"line_number":249,"context_line":"[8] http://docs.openstack.org/developer/ironic/"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba3cc151_3cfe156c","line":249,"updated":"2015-06-29 17:46:20.000000000","message":"[9] https://en.wikipedia.org/wiki/Feature_toggle","commit_id":"1d15e84b7844a49b9cdd473b76f654f096609a97"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"4d07484ac02858f719465ecc93d82d21ec14462c","unresolved":false,"context_lines":[{"line_number":76,"context_line":"  functionality or code. Ironic should never do a release without an upgrade"},{"line_number":77,"context_line":"  path from a prior release, so in traditional SemVer the major version would"},{"line_number":78,"context_line":"  never change. We should bump minor and patch versions as needed for"},{"line_number":79,"context_line":"  minor feature and bug fix releases."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_09364652","line":79,"updated":"2015-06-30 14:26:46.000000000","message":"I don\u0027t care much what exactly we do, but I don\u0027t agree with understanding of semver here. I believe that major version is bumped whenever upgrade path is different from \"update source, run migrations and restart\". Particularly, I think that when we tell people things like \"you should upgrade Nova first\", we should bump major version.","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"502531002b1217224ca5380e272d57eca9e5c957","unresolved":false,"context_lines":[{"line_number":76,"context_line":"  functionality or code. Ironic should never do a release without an upgrade"},{"line_number":77,"context_line":"  path from a prior release, so in traditional SemVer the major version would"},{"line_number":78,"context_line":"  never change. We should bump minor and patch versions as needed for"},{"line_number":79,"context_line":"  minor feature and bug fix releases."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"* Ironic releases should be published to PyPI."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_a76b65b8","line":79,"in_reply_to":"ba3cc151_09364652","updated":"2015-07-02 02:36:30.000000000","message":"I guess that makes sense. I\u0027m hoping we\u0027re done with that at this point, though.","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"4d07484ac02858f719465ecc93d82d21ec14462c","unresolved":false,"context_lines":[{"line_number":87,"context_line":"    * One \"approved\" directory where all specs live initially."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    * Separate $version-implemented directories that house the specs that were"},{"line_number":90,"context_line":"      implemented in $version of Ironic."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Leading up to all releases, reviewers should honor a \"soft freeze\" period of"},{"line_number":93,"context_line":"  a few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_2939ca41","line":90,"updated":"2015-06-30 14:26:46.000000000","message":"Alternative proposal: just group them in index.rst, but don\u0027t move, so that URL\u0027s don\u0027t break. It\u0027s a fine feature of the current layout, that once URL is generated for a spec, you can use it as permlink.","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"502531002b1217224ca5380e272d57eca9e5c957","unresolved":false,"context_lines":[{"line_number":87,"context_line":"    * One \"approved\" directory where all specs live initially."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    * Separate $version-implemented directories that house the specs that were"},{"line_number":90,"context_line":"      implemented in $version of Ironic."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Leading up to all releases, reviewers should honor a \"soft freeze\" period of"},{"line_number":93,"context_line":"  a few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_676a3db5","line":90,"in_reply_to":"ba3cc151_2939ca41","updated":"2015-07-02 02:36:30.000000000","message":"Yeah, probably a good idea.","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"30ea7a1e477f08f9a9392e3a7e833f19deeb0e1d","unresolved":false,"context_lines":[{"line_number":87,"context_line":"    * One \"approved\" directory where all specs live initially."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"    * Separate $version-implemented directories that house the specs that were"},{"line_number":90,"context_line":"      implemented in $version of Ironic."},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"* Leading up to all releases, reviewers should honor a \"soft freeze\" period of"},{"line_number":93,"context_line":"  a few days to a week. Code that is risky in terms of breakage should probably"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_41981b6a","line":90,"in_reply_to":"ba3cc151_2939ca41","updated":"2015-07-02 19:54:56.000000000","message":"alternate suggestion:\n\n- keep the \"approved\" directory\n- when work is completed, move spec to $version-implemented directory\n- and create a placeholder at the old location which indicates the release it was complete in, and a link (maybe even a redirect) to the new location\n\nIn this way, the \"approved\" directory serves as a single point of truth for \"designs which are approved but not completed yet\". And it gives us a cleaner way to track changes across releases, eg, if we have to rev the design of a feature in release N and N+2, we would end up with two specs (showing what was done in each release) rather than just one (showing the most recently approved state).","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":2889,"name":"Aeva Black","email":"aeva.online@gmail.com","username":"tenbrae"},"change_message_id":"30ea7a1e477f08f9a9392e3a7e833f19deeb0e1d","unresolved":false,"context_lines":[{"line_number":92,"context_line":"* Leading up to all releases, reviewers should honor a \"soft freeze\" period of"},{"line_number":93,"context_line":"  a few days to a week. Code that is risky in terms of breakage should probably"},{"line_number":94,"context_line":"  not land at this time; quick bug fixes, driver changes, and other less risky"},{"line_number":95,"context_line":"  changes should be okay to land in most cases. The PTL must be sure to"},{"line_number":96,"context_line":"  communicate upcoming releases and these freezes well."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* Ironic may need to decouple from global requirements during Dep Freeze[7]."}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_21a2b799","line":95,"updated":"2015-07-02 19:54:56.000000000","message":"s/PTL/PTL or designated release manager/","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"4d07484ac02858f719465ecc93d82d21ec14462c","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":103,"context_line":"  This should only happen on an as-needed basis as the problem arises; not"},{"line_number":104,"context_line":"  by default. We also may need to temporarily drop the"},{"line_number":105,"context_line":"  \"gate-ironic-requirements\" job during this time. Finally, any patches to"},{"line_number":106,"context_line":"  Ironic changing requirements.txt should also have a patch to"},{"line_number":107,"context_line":"  global-requirements with a general \"looks good\" from a global-requirements"},{"line_number":108,"context_line":"  core reviewer."}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_c9405ea8","line":105,"updated":"2015-06-30 14:26:46.000000000","message":"oh... I understand that it goes beyond this spec, but I\u0027d prefer global-requirements to cut stable/XXX at the beginning of the depfreeze instead. Projects that respect depfreeze will switch to it, other will remain on master.","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"502531002b1217224ca5380e272d57eca9e5c957","unresolved":false,"context_lines":[{"line_number":102,"context_line":"  Freeze, as the stable branch has already been cut by this point."},{"line_number":103,"context_line":"  This should only happen on an as-needed basis as the problem arises; not"},{"line_number":104,"context_line":"  by default. We also may need to temporarily drop the"},{"line_number":105,"context_line":"  \"gate-ironic-requirements\" job during this time. Finally, any patches to"},{"line_number":106,"context_line":"  Ironic changing requirements.txt should also have a patch to"},{"line_number":107,"context_line":"  global-requirements with a general \"looks good\" from a global-requirements"},{"line_number":108,"context_line":"  core reviewer."}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_67b1dd46","line":105,"in_reply_to":"ba3cc151_c9405ea8","updated":"2015-07-02 02:36:30.000000000","message":"+1 :)","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"4d07484ac02858f719465ecc93d82d21ec14462c","unresolved":false,"context_lines":[{"line_number":152,"context_line":"------------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"As the Nova driver is released with Nova, it will not change in terms of the"},{"line_number":155,"context_line":"way it is released."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Security impact"},{"line_number":158,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_e93be236","line":155,"updated":"2015-06-30 14:26:46.000000000","message":"Note that we\u0027ll have to keep compatibility with older Nova driver during the whole cycle.","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"502531002b1217224ca5380e272d57eca9e5c957","unresolved":false,"context_lines":[{"line_number":152,"context_line":"------------------"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"As the Nova driver is released with Nova, it will not change in terms of the"},{"line_number":155,"context_line":"way it is released."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"Security impact"},{"line_number":158,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba3cc151_27b7553b","line":155,"in_reply_to":"ba3cc151_e93be236","updated":"2015-07-02 02:36:30.000000000","message":"+1, I don\u0027t think anyone has debated that.","commit_id":"4d5f95aa70e2fc3c615feb3571b1b5c9bcd7724d"}]}