HTML version: http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160318-2/
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 -> stable/mitaka and stable/mitaka -> master. * Tell us yours via IRC with a message “#success [insert success]”. * All: https://wiki.openstack.org/wiki/Successes PTL Election Conclusion and Results =================================== * Results are in, congrats to everyone! [2] * Appointed PTLs by the TC for leaderless Projects [3]: - EC-API: Alex Andrelevine - Stable Branch Maintenance: Tony Breeds - Winstackers: Claudiu Belu Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html Candidate Proposals for Technical Committee Positions Are Now Open =================================================================== * Important dates: - Nominations open: 2016-03-25 00:00 UTC - Nominations close: 2016-03-31 23:59 UTC - Election open: 2015-04-01 00:00 UTC - Election close: 2015-04-07 23:59 UTC * More details on the election [4] * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090421.html Release countdown for week R-1, Mar 27 - Apr 1 ============================================== * Focus: - Project teams following the cycle-with-milestone model should be testing their release Candidates. - 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. - All projects should be working on release-critical-bugs. * General Notes: - Global-requirements list is still frozen. - If you need to change a dependency for release-critical-bug fix, provide enough details in the change request. - Master branches for all projects following cycle-with-milestone are open for Newton development work. * Release Actions: - Projects following cycle-with-intermediary without clear indication of cutting their final release: + bifrost + magnum + python-searchlightclient + senlin-dashboard + solum-infra-guestagent + os-win + cloudkitty + tacker - 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. + After March 31st, feature releases will be counted as part of Newton cycle. - 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 "[release]" in the subject. * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/089701.html Bots and Their Effects: Gerrit, IRC, other ========================================== * Bots are very handy for doing repetitive tasks. * 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 * From an infra meeting [5], this is what has been raised so far: - Permissions: having a bot on gerrit with +2 +A is something we would like to avoid - "unsanctioned" bots (bots not in infra config files) in channels shared by multiple teams (meeting channels, the -dev channel) - Forming a dependence on bots and expecting infra to maintain them ex post facto (example: bot soren maintained until soren didn't) - Causing irritation for others due to the presence of an echoing bot which eventually infra will be asked or expected to mediate - Duplication of features, both meetbot and purplebot log channels and host the archives in different locations - Canonical bot doesn't get maintained * It's possible bots that infra currently maintains have features that folks are unaware of. * Bots that +2 reviews and approve them can be a problem when taking into account of schedules, outages, gate issues, etc. * The Success bot for example is and added feature that takes advantage of the already existing status bot. * What are the reasons that people end up writing their own bots instead of contributing to the existing infrastructure bots when applicable? * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90262 Semantic Version On Master Branches After RC ============================================ * The release team assumes three options someone would choose when installing things: - Tagged versions from any branch. + Clear, and always produces deployments that are reproduceable, with versions distinct and increasing over time. - Untagged versions on a stable branch. - Untagged versions on the master branch + Options 2 and 3 are something around release cycle boundaries. + Produce the same version numbers in different branches for a short period of time. + The release team felt it was extremely unlikely that anyone would mix option 2 and 3, because that will make upgrades difficult. * Some distributions want to package things that are not tagged as releasable by contributors. - Consumers + They are in their development cycles and want/need to keep up with trunk throughout the whole cycle. + A lot of changes are introduced in a cycle with new features, deprecations, removals, non-backwards compatibility etc. Wit these continually provided up-to-date packages, they are able to test them right away. - It's a lot of work to package things, and distributions want to do it quickly. + If distributions started packaging OpenStack only when the official stable release would be out, it would take us several weeks/months to get a stable package out. + 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). * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90149 Our Install Guides Only Cover Defcore - What About Big Tent? ============================================================ * Until recently, projects like Manila [6] and Magnum have been accepted in the install guides, but we're having issues initially because they aren't considered by the defcore working group. - With expansion of projects coming from big tent, the documentation team has projects requesting their install documentation to be accepted. 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. * Goals: - Make install guides easy to contribute for projects in the big tent. - Not end up having the documentation team maintain all projects install documentation. - As an operator, I should be able to easily discover install documentation for projects in the big tent. - With accessible install documentation projects can hopefully have: + Improved adoption + More stable work from bug reports with people actually able to install and test the project. * Proposal: Install documentation can live in a project's repository so they can maintain and update. - Have all these documentation sources rendered to one location for easy discoveribility. * Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90214 [1] - http://developer.openstack.org/api-guide/key-manager/ [2] - http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html [3] - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-03-22-20.01.html [4] - https://wiki.openstack.org/wiki/TC_Elections_April_2016 [5] - http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-22-19.02.log.html [6] - https://review.openstack.org/#/c/213756/ _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
