{"id":7483,"date":"2015-11-27T14:27:54","date_gmt":"2015-11-27T20:27:54","guid":{"rendered":"http:\/\/www.openstack.org\/blog\/?p=7483"},"modified":"2015-11-27T14:27:54","modified_gmt":"2015-11-27T20:27:54","slug":"openstack-developer-mailing-list-digest-november-20151121","status":"publish","type":"post","link":"https:\/\/www.openstack.org\/blog\/openstack-developer-mailing-list-digest-november-20151121\/","title":{"rendered":"OpenStack Developer Mailing List Digest November 21-27"},"content":{"rendered":"<h1><a href=\"https:\/\/wiki.openstack.org\/wiki\/Successes\">Success Bot Says<\/a><\/h1>\n<ul>\n<li>vkmc: We got 7 new interns for the Outreachy program December-March 2015 round.<\/li>\n<li>bauzas: Reno in place for Nova release notes.<\/li>\n<li>AJaeger:\u00a0We now have Japanese Install Guides published for Liberty [1].<\/li>\n<li>robcresswell:\u00a0Horizon had a bug day! We made good progress on categorizing new bugs and removing old ones, with many members of the community stepping up to help.<\/li>\n<li>AJaeger:\u00a0The OpenStack Architecture Design Guide has been converted to RST [2].<\/li>\n<li>AJaeger:\u00a0The Virtual Machine Image guide has been converted to RST [3].<\/li>\n<li>Ajaeger:\u00a0Japanese Networking Guide is published as draft [4].<\/li>\n<li>Tell us yours via IRC with a message \u201c#success [insert success]\u201d.<\/li>\n<\/ul>\n<div><\/div>\n<h1><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080527.html\">Release countdown for week R-18, Nov 30 &#8211;\u00a0Dec 4<\/a><\/h1>\n<ul>\n<li>All projects following the cycle-with-milestones release model should be preparing for the milestone tag.<\/li>\n<li>Release Actions:\n<ul>\n<li>All deliverables must have Reno configured before adding a Mitaka-1 milestone tag.<\/li>\n<li>Use openstack\/releases repository to manage the Mitaka-1 milestone tags.<\/li>\n<li>One time change, we will be simplifying how we specify the versions for projects by moving to only using tags instead of the version entry for setup.cfg.<\/li>\n<\/ul>\n<\/li>\n<li>Stable release actions: Review stable\/liberty branches for patches that have landed since the last release and determine if your deliverables need new tags.<\/li>\n<li>Important dates:\n<ul>\n<li>Deadline for requesting a Mitaka-1 milestone tag: December 3rd<\/li>\n<li>Mitaka-2: Jan 19-21<\/li>\n<li>Mitaka release schedule [5]<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<div><\/div>\n<h1><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080058.html\">Common OpenStack\u00a0\u2018Third-Party\u2019\u00a0CI Solution &#8211; DONE!<\/a><\/h1>\n<ul>\n<li>Ramy Asselin who has been spearheading the work for a common third-party CI solution announces things being done!\n<ul>\n<li>This solution uses the same tools and scripts as the upstream Jenkins CI solution.<\/li>\n<li>The documentation for setting up a 3rd party ci system on 2 VMs (1 private that\u00a0runs the CI jobs, and 1 public that hosts the log files) is now available here\u00a0[6] or [7].<\/li>\n<li>There a number of companies today using this solution for their third party CI needs.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<div><\/div>\n<h1><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/078280.html\">Process Change For Closing Bugs When Patches Merge<\/a><\/h1>\n<ul>\n<li>Today when a patch merges with \u2018Closes-Bug\u2019 in the commit message, that marks the associated bug as \u2018Fix Committed\u2019 to indicated fixed, but not in the release yet.<\/li>\n<li>The release team uses automated tools to mark bugs from \u2018Fix Committed\u2019 to \u2018Fix Released\u2019, but they\u2019re not reliable due to Launchpad issues.<\/li>\n<li>Proposal for automated tools to improve reliability: Patches with \u2018Closes-Bug\u2019 in the commit message to have the bug status mark the associated bug as \u2018Fix Released\u2019 instead of \u2018Fix Committed\u2019.<\/li>\n<li>Doug would like to have this be in effect next week.<\/li>\n<\/ul>\n<div><\/div>\n<h1><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080238.html\">Move From Active Distrusting Model to Trusting Model<\/a><\/h1>\n<ul>\n<li>Morgan Fainberg writes most projects have a distrusting policy that prevents the following scenario:\n<ul>\n<li>Employee from Company A writes code<\/li>\n<li>Other Employee from Company A reviews code<\/li>\n<li>Third Employee from Company A reviews and approves code.<\/li>\n<\/ul>\n<\/li>\n<li>Proposal for a trusting model:\n<ul>\n<li>Code reviews still need 2x Core Reviewers (no change)<\/li>\n<li>Code can be developed by a member of the same company as both core\u00a0reviewers (and approvers).<\/li>\n<li>If the trust that is being given via this new policy is violated, the\u00a0code can [if needed], be reverted (we are using git here) and the actors in\u00a0question can lose core status (PTL discretion) and the policy can be\u00a0changed back to the &#8220;distrustful&#8221; model described above.<\/li>\n<\/ul>\n<\/li>\n<li>Dolph Mathews provides scenarios where the \u201cdistrusting\u201d model either did or would have helped:\n<ul>\n<li>Employee is reprimanded by management for not positively reviewing &amp;\u00a0approving a coworkers patch.<\/li>\n<li>A team of employees is pressured to land a feature with as fast as\u00a0possible. Minimal community involvement means a faster path to &#8220;merged,\u201d\u00a0right?<\/li>\n<li>A large group of reviewers from the author&#8217;s organization repeatedly\u00a0throwing *many* careless +1s at a single patch. (These happened to not be\u00a0cores, but it&#8217;s a related organizational behavior taken to an extreme.)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<div><\/div>\n<h1><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080249.html\">Stable Team PTL Nominations Are Open<\/a><\/h1>\n<ul>\n<li>As discussed [8][9] of setting up a standalone stable maintenance team, we\u2019ll be organizing PTL elections over the coming weeks.<\/li>\n<li>Stable team\u2019s mission:\n<ul>\n<li>Define and enforce the common stable branch policy<\/li>\n<li>Educate and accompany projects as they use stable branches<\/li>\n<li>Keep CI working on stable branches<\/li>\n<li>Mentoring\/growing the stable maintenance team<\/li>\n<li>Create and improve stable tooling\/automation<\/li>\n<\/ul>\n<\/li>\n<li>Anyone who successfully contributed to a stable branch back port over the last year can vote in the stable PTL election.<\/li>\n<li>If interested, reply to thread with your self-nomination.<\/li>\n<li>Deadline is 23:59 UTC Monday, November 30.<\/li>\n<li>Election will be the week after.<\/li>\n<li>Current candidates:\n<ul>\n<li>Matt Riedmann [10]<\/li>\n<li>Erno Kuvaja [11]<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<div><\/div>\n<h1><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080694.html\">Using Reno For Libraries<\/a><\/h1>\n<ul>\n<li>Libraries have two audiences for release notes:\n<ul>\n<li>Developers consuming the library.<\/li>\n<li>Deployers pushing out new versions of the libraries.<\/li>\n<\/ul>\n<\/li>\n<li>To separate the notes from the two audiences and avoid doing manually something that we have been doing automatically, we can use Reno for just deployer release notes.<\/li>\n<li>Library repositories that need Reno should have it configured like service projects, with separate jobs and a publishing location different from their developer documentation [12]<\/li>\n<\/ul>\n<div><\/div>\n<h1><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080233.html\">Releases VS Development Cycle<\/a><\/h1>\n<ul>\n<li>Thierry writes that as more projects enter the Big Tent, there have recently been questions about release models and development cycle.<\/li>\n<li>Some projects want to be independent of the common release cycle and dates, but still keep some adherence to the development cycle. Examples:\n<ul>\n<li>Gnocchi wants to be completely independent of the common development cycle, but still maintain stable branches.<\/li>\n<li>Fuel traditionally makes their releases a few months behind the OpenStack release to integration all the functionality there.<\/li>\n<\/ul>\n<\/li>\n<li>All projects above should current be release:independent, until they are able to (and willing) to coordinate their own releases with the projects following the common release cycle.<\/li>\n<li>The release team currently supports 3 models:\n<ul>\n<li>release:cycle-with-milestones is the traditional Nova model with one\u00a0release at the end of a 6-month dev cycle and a stable branch derived\u00a0from that.<\/li>\n<li>release:cycle-with-intermediary is the traditional Swift model, with\u00a0releases as-needed during the 6-month development cycle, and a stable\u00a0branch created from the last release in the cycle.<\/li>\n<li>release:independent, for projects that don&#8217;t follow the release cycle\u00a0at all.\n<ul>\n<li>Can make a release supporting the Mitaka release (including stable updates).\n<ul>\n<li>Can call the branch stable\/mitaka even after the Mitaka release cycle, as long as the branch is stable and not development.<\/li>\n<\/ul>\n<\/li>\n<li>Should clearly document that their release is *compatible with* the OpenStack Mitaka release, rather than *part of* the Mitaka release.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<div><\/div>\n<div>[1] &#8211;\u00a0<a href=\"http:\/\/docs.openstack.org\/ja\/\">http:\/\/docs.openstack.org\/ja\/<\/a><\/div>\n<div>[2] &#8211;\u00a0<a href=\"http:\/\/docs.openstack.org\/arch-design\/\">http:\/\/docs.openstack.org\/arch-design\/<\/a><\/div>\n<div>[3] &#8211;\u00a0<a href=\"http:\/\/docs.openstack.org\/image-guide\/\">http:\/\/docs.openstack.org\/image-guide\/<\/a><\/div>\n<div>[4] &#8211;\u00a0<a href=\"http:\/\/docs.openstack.org\/draft\/ja\/networking-guide\/\">http:\/\/docs.openstack.org\/draft\/ja\/networking-guide\/<\/a><\/div>\n<div>[5] &#8211;\u00a0<a href=\"https:\/\/wiki.openstack.org\/wiki\/Mitaka_Release_Schedule\">https:\/\/wiki.openstack.org\/wiki\/Mitaka_Release_Schedule<\/a><\/div>\n<div>[6] &#8211; <a href=\"https:\/\/github.com\/openstack-infra\/puppet-openstackci\/tree\/master\/contrib\">https:\/\/github.com\/openstack-infra\/puppet-openstackci\/tree\/master\/contrib<\/a><\/div>\n<div>[7] &#8211;\u00a0<a href=\"https:\/\/git.openstack.org\/cgit\/openstack-infra\/puppet-openstackci\/tree\/contrib\/README.md\">https:\/\/git.openstack.org\/cgit\/openstack-infra\/puppet-openstackci\/tree\/contrib\/README.md<\/a><\/div>\n<div>[8] &#8211;\u00a0<a href=\"http:\/\/www.openstack.org\/blog\/2015\/11\/openstack-developer-mailing-list-digest-november-20151107\/#stable-team\">http:\/\/www.openstack.org\/blog\/2015\/11\/openstack-developer-mailing-list-digest-november-20151107\/#stable-team<\/a><\/div>\n<div>[9] &#8211;\u00a0<a href=\"http:\/\/www.openstack.org\/blog\/2015\/11\/openstack-developer-mailing-list-digest-november-20151114\/#stable-team\">http:\/\/www.openstack.org\/blog\/2015\/11\/openstack-developer-mailing-list-digest-november-20151114\/#stable-team<\/a><\/div>\n<div>[10] &#8211;\u00a0<a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080262.htm\">http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080262.htm<\/a>l<\/div>\n<div>[11] &#8211;\u00a0<a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080607.html\">http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-November\/080607.html<\/a><\/div>\n<div><a href=\"http:\/\/www.openstack.org\/blog\/2015\/11\/openstack-developer-mailing-list-digest-november-7-13\/#reno\">[<\/a>12] &#8211;\u00a0<a href=\"http:\/\/docs.openstack.org\/developer\/reno\/\">http:\/\/docs.openstack.org\/developer\/reno\/<\/a><\/div>\n","protected":false},"excerpt":{"rendered":"<p>Success Bot Says vkmc: We got 7 new interns for the Outreachy program December-March 2015 round. bauzas: Reno in place for Nova release notes. AJaeger:\u00a0We now have Japanese Install Guides published for Liberty [1]. robcresswell:\u00a0Horizon had a bug day! We made good progress on categorizing new bugs and removing old ones, with many members of&#8230;  <a href=\"https:\/\/www.openstack.org\/blog\/openstack-developer-mailing-list-digest-november-20151121\/\" class=\"more-link\" title=\"Read OpenStack Developer Mailing List Digest November 21-27\">Read more &raquo;<\/a><\/p>\n","protected":false},"author":82,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7483"}],"collection":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/users\/82"}],"replies":[{"embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/comments?post=7483"}],"version-history":[{"count":1,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7483\/revisions"}],"predecessor-version":[{"id":7484,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7483\/revisions\/7484"}],"wp:attachment":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/media?parent=7483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/categories?post=7483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/tags?post=7483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}