{"id":7697,"date":"2016-03-25T22:08:35","date_gmt":"2016-03-26T03:08:35","guid":{"rendered":"http:\/\/www.openstack.org\/blog\/?p=7697"},"modified":"2016-03-25T22:08:35","modified_gmt":"2016-03-26T03:08:35","slug":"openstack-developer-mailing-list-digest-20160318-2","status":"publish","type":"post","link":"https:\/\/www.openstack.org\/blog\/openstack-developer-mailing-list-digest-20160318-2\/","title":{"rendered":"OpenStack Developer Mailing List Digest March 19-25"},"content":{"rendered":"<h1 class=\"western\">SuccessBot Says<\/h1>\n<ul>\n<li>redrobot: The Barbican API guides is now being published. <a href=\"http:\/\/developer.openstack.org\/api-guide\/key-manager\/\">[1]<\/a><\/li>\n<li>jroll: ironic 5.1.0 released as the basis for stable\/mitaka.<\/li>\n<li>ttx: All RC1s up for milestones-driven projects.<\/li>\n<li>zara: storyboard.openstack.org sends emails now!<\/li>\n<li>noggin143: my first bays running on CERN production cloud with Magnum.<\/li>\n<li>sdague: Grenade upgraded to testing stable\/liberty -&gt; stable\/mitaka and stable\/mitaka -&gt; master.<\/li>\n<li>Tell us yours via IRC with a message \u201c#success [insert success]\u201d.<\/li>\n<li><a href=\"https:\/\/wiki.openstack.org\/wiki\/Successes\">All<\/a><\/li>\n<\/ul>\n<h1 class=\"western\">PTL Election Conclusion and Results<\/h1>\n<ul>\n<li>Results are in, congrats to everyone! <a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2016-March\/090422.html\">[2]<\/a><\/li>\n<li>Appointed PTLs by the TC for leaderless Projects <a href=\"http:\/\/eavesdrop.openstack.org\/meetings\/tc\/2016\/tc.2016-03-22-20.01.html\">[3]<\/a>:\n<ul>\n<li>EC-API: Alex Andrelevine<\/li>\n<li>Stable Branch Maintenance: Tony Breeds<\/li>\n<li>Winstackers: Claudiu Belu<\/li>\n<\/ul>\n<\/li>\n<li><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2016-March\/090422.html\">Full thread<\/a><\/li>\n<\/ul>\n<h1 class=\"western\">Candidate Proposals for Technical Committee Positions Are Now Open<\/h1>\n<ul>\n<li>Important dates:\n<ul>\n<li>Nominations open: 2016-03-25 00:00 UTC<\/li>\n<li>Nominations close: 2016-03-31 23:59 UTC<\/li>\n<li>Election open: 2015-04-01 00:00 UTC<\/li>\n<li>Election close: 2015-04-07 23:59 UTC<\/li>\n<\/ul>\n<\/li>\n<li>More details on the election <a href=\"https:\/\/wiki.openstack.org\/wiki\/TC_Elections_April_2016\">[4]<\/a><\/li>\n<li><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2016-March\/090421.html\">Full thread<\/a><\/li>\n<\/ul>\n<h1 class=\"western\">Release countdown for week R-1, Mar 27 &#8211; Apr 1<\/h1>\n<ul>\n<li>Focus:\n<ul>\n<li>Project teams following the cycle-with-milestone model should be testing their release Candidates.<\/li>\n<li>Project teams following the cycle-with-intermediary model should have at least one Mitaka release and determine if another release is needed before the end of the Mitaka cycle.<\/li>\n<li>All projects should be working on release-critical-bugs.<\/li>\n<\/ul>\n<\/li>\n<li>General Notes:\n<ul>\n<li>Global-requirements list is still frozen.<\/li>\n<li>If you need to change a dependency for release-critical-bug fix, provide enough details in the change request.<\/li>\n<li>Master branches for all projects following cycle-with-milestone are open for Newton development work.<\/li>\n<\/ul>\n<\/li>\n<li>Release Actions:\n<ul>\n<li>Projects following cycle-with-intermediary without clear indication of cutting their final release:\n<ul>\n<li>bifrost<\/li>\n<li>magnum<\/li>\n<li>python-searchlightclient<\/li>\n<li>senlin-dashboard<\/li>\n<li>solum-infra-guestagent<\/li>\n<li>os-win<\/li>\n<li>cloudkitty<\/li>\n<li>tacker<\/li>\n<\/ul>\n<\/li>\n<li>These projects should contact the release team or submit a release request to the releases repository as soon as possible. Please submit a request by Wednesday or Thursday at the latest.\n<ul>\n<li>After March 31st, feature releases will be counted as part of Newton cycle.<\/li>\n<\/ul>\n<\/li>\n<li>The release team will have reduced availability between R1 and summit due to travel. Use the dev mailing list to contact the team and include &#8220;[release]&#8221; in the subject.<\/li>\n<\/ul>\n<\/li>\n<li><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2016-March\/089701.html\">Full thread<\/a><\/li>\n<\/ul>\n<h1 class=\"western\">Bots and Their Effects: Gerrit, IRC, other<\/h1>\n<ul>\n<li>Bots are very handy for doing repetitive tasks.<\/li>\n<li>These require require permissions to execute certain actions, require maintenance to ensure they operate as expected and do create output which is music to some and noise to others<\/li>\n<li>From an infra meeting <a href=\"http:\/\/eavesdrop.openstack.org\/meetings\/infra\/2016\/infra.2016-03-22-19.02.log.html\">[5]<\/a>, this is what has been raised so far:\n<ul>\n<li>Permissions: having a bot on gerrit with +2 +A is something we would like to avoid<\/li>\n<li>&#8220;unsanctioned&#8221; bots (bots not in infra config files) in channels shared by multiple teams (meeting channels, the -dev channel)<\/li>\n<li>Forming a dependence on bots and expecting infra to maintain them ex post facto (example: bot soren maintained until soren didn&#8217;t)<\/li>\n<li>Causing irritation for others due to the presence of an echoing bot which eventually infra will be asked or expected to mediate<\/li>\n<li>Duplication of features, both meetbot and purplebot log channels and host the archives in different locations<\/li>\n<li>Canonical bot doesn&#8217;t get maintained<\/li>\n<\/ul>\n<\/li>\n<li>It&#8217;s possible bots that infra currently maintains have features that folks are unaware of.<\/li>\n<li>Bots that +2 reviews and approve them can be a problem when taking into account of schedules, outages, gate issues, etc.<\/li>\n<li>The Success bot for example is and added feature that takes advantage of the already existing status bot.<\/li>\n<li>What are the reasons that people end up writing their own bots instead of contributing to the existing infrastructure bots when applicable?<\/li>\n<li><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2016-March\/thread.html#90262\">Full thread<\/a><\/li>\n<\/ul>\n<h1 class=\"western\">Semantic Version On Master Branches After Release Candidates<\/h1>\n<ul>\n<li>The release team assumes three options someone would choose when installing things:\n<ul>\n<li>Tagged versions from any branch.\n<ul>\n<li>Clear, and always produces deployments that are reproduceable, with versions distinct and increasing over time.<\/li>\n<\/ul>\n<\/li>\n<li>Untagged versions on a stable branch.<\/li>\n<li>Untagged versions on the master branch\n<ul>\n<li>Options 2 and 3 are something around release cycle boundaries.<\/li>\n<li>Produce the same version numbers in different branches for a short period of time.<\/li>\n<li>The release team felt it was extremely unlikely that anyone would mix option 2 and 3, because that will make upgrades difficult.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Some distributions want to package things that are not tagged as releasable by contributors.\n<ul>\n<li>Consumers\n<ul>\n<li>They are in their development cycles and want\/need to keep up with trunk throughout the whole cycle.<\/li>\n<li>A lot of changes are introduced in a cycle with new features, deprecations, removals, non-backwards compatibility etc. With these continually provided up-to-date packages, they are able to test them right away.<\/li>\n<\/ul>\n<\/li>\n<li>It&#8217;s a lot of work to package things, and distributions want to do it quickly.\n<ul>\n<li>If distributions started packaging OpenStack only when the official stable release would be out, it would take distributions several weeks\/months to get a stable package out.<\/li>\n<li>Projects that use packages to deploy are then delayed for their own release to test these packages their consuming. (e.g. TripleO, Packstack, Kolla, Puppet-OpenStack).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2016-March\/thread.html#90149\">Full thread<\/a><\/li>\n<\/ul>\n<h1 class=\"western\">Our Install Guides Only Cover Defcore &#8211; What About Big Tent?<\/h1>\n<ul>\n<li>Until recently, projects like Manila <a href=\"https:\/\/review.openstack.org\/#\/c\/213756\/\">[6]<\/a> and Magnum have been accepted in the install guides, but we&#8217;re having issues initially because they aren&#8217;t considered by the defcore working group.\n<ul>\n<li>With expansion of projects coming from big tent, the documentation team has projects requesting their install documentation to be accepted.<\/li>\n<li>The documentation team today maintain and verifies the install documentation for each release can be a lot of work with the already accepted OpenStack projects.<\/li>\n<\/ul>\n<\/li>\n<li>Goals:\n<ul>\n<li>Make install guides easy to contribute for projects in the big tent.<\/li>\n<li>Not end up having the documentation team maintain all projects install documentation.<\/li>\n<li>As an operator, I should be able to easily discover install documentation for projects in the big tent.<\/li>\n<li>With accessible install documentation projects can hopefully have:\n<ul>\n<li>Improved adoption<\/li>\n<li>More stable work from bug reports with people actually able to install and test the project.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Proposal: Install documentation can live in a project&#8217;s repository so they can maintain and update.\n<ul>\n<li>Have all these documentation sources rendered to one location for easy discoverability .<\/li>\n<\/ul>\n<\/li>\n<li><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2016-March\/thread.html#90214\">Full thread<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>SuccessBot Says redrobot: The Barbican API guides is now being published. [1] jroll: ironic 5.1.0 released as the basis for stable\/mitaka. ttx: All RC1s up for milestones-driven projects. zara: storyboard.openstack.org sends emails now! noggin143: my first bays running on CERN production cloud with Magnum. sdague: Grenade upgraded to testing stable\/liberty -&gt; stable\/mitaka and stable\/mitaka -&gt;&#8230;  <a href=\"https:\/\/www.openstack.org\/blog\/openstack-developer-mailing-list-digest-20160318-2\/\" class=\"more-link\" title=\"Read OpenStack Developer Mailing List Digest March 19-25\">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\/7697"}],"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=7697"}],"version-history":[{"count":6,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7697\/revisions"}],"predecessor-version":[{"id":7703,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7697\/revisions\/7703"}],"wp:attachment":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/media?parent=7697"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/categories?post=7697"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/tags?post=7697"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}