Open Stack

HTML version: https://www.openstack.org/blog/2017/09/developer-mailing-list-digest-september-23-29-2017/

# Summaries
* [TC Report 39](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122679.html)
* [Release countdown for week R-21,    September 29 - October 6](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122819.html)
* [Technical committee status update, September 29](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122879.html)
* [Placement/resource providers update 36](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122883.html)
* [POST /api-sig/news](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122805.html)

## Sydney Forum

### General Links
* [What the heck is the form?](https://wiki.openstack.org/wiki/Forum)
* When: November 6-8, 2017
* Where: OpenStack Summit in Sydney Australia
* Register for [The OpenStack Sydney Summit](https://www.openstack.org/summit/sydney-2017/) and show up!
* Deadline for topic sessions was September 29th UTC by this [submission form](http://forumtopics.openstack.org/).
* [All Sydney Forum etherpads](https://wiki.openstack.org/wiki/Forum/Sydney2017)

### Etherpads (copied from Sydney Forum wiki)

#### Catch-alls
If you want to post an idea, but aren’t working with a specific team or working group, you can use these:

    * [Technical Committee Catch-all](https://etherpad.openstack.org/p/SYD-TC-brainstorming) 
    * [User Committee Catch-all](https://etherpad.openstack.org/p/SYD-UC-brainstorming) 

#### Etherpads from Teams and Working Groups
    * [Nova](https://etherpad.openstack.org/p/SYD-nova-brainstorming) 
    * [Cinder](https://etherpad.openstack.org/p/cinder-sydney-forum-topics) 
    * [Ops Meetups Team](https://etherpad.openstack.org/p/SYD-ops-session-ideas) 
    * [OpenStack Ansible](https://etherpad.openstack.org/p/osa-sydney-summit-planning) 
    * [Self-healing SIG](https://etherpad.openstack.org/p/self-healing-rocky-forum) 
    * [Neutron Quality-Of-Service Discussion](https://etherpad.openstack.org/p/qos-talk-sydney) 
    * [QA Team](https://etherpad.openstack.org/p/qa-sydney-forum-topics) 
    * [Watcher](https://etherpad.openstack.org/p/watcher-Sydney-meetings) 
    * [SIG K8s](https://etherpad.openstack.org/p/sig-k8s-sydney-forum-topics) 
    * [Kolla](https://etherpad.openstack.org/p/kolla-sydney-forum-topics) 


## Garbage Patches for Simple Typos Fixes
* There is some agreement that we as a community have to do something beyond mentoring new developers.
    * Others have mentioned that some companies are doing this to game the system in other communities besides OpenStack.
        * Gain: show a high contribution level was “low quality” patches.
    * Some people in the community want to put a stop to this figuratively with a stop sign, otherwise things will never improve. If we don't do something now we are hurting everyone, including those developers who could have done more meaningful contributions.
    * Others would like before we go into creating harsh processes, we need to collect the data to show other times to provide guidance I Have not worked.
    * We have a lot of anecdotal information right now that we need to collect and summarize.
    * If the results show that there are clear abuses, rather than misunderstandings, then we can use that data to design effective blocks without hurting other contributors or creating a reputation that our community is not welcoming.
* Some are unclear why there is so much outrage about these patches to begin with. They are fixing real things.
    * Maybe there is a CI cost, but the faster they are merged the less likely someone is to propose it in the future which keeps the CI cost down.
    * If people are deeply concerned about CI resources, step one is to give us a better accounting into their existing system to see where resources are currently spent. 
* [Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122472)


## Status of the Stewardship Working Group
* The stewardship working group was created after the first session of leadership training that the Technical Committee, User Committee, Board and other community members were invited to participate in 2016.
* Follow-up on what we learned at ZingTrain and push adoption of the tools we discovered there.
* While we did (and continue)
    * The activity of the workgroup mostly died when we decided to experiment getting rid of weekly meetings for greater inclusion.
    * Lost original leadership.
* The workgroup is dormant, until someone steps up and leads it again.
* Join us on IRC Freenode in channel openstack-swg if interested.
* [Message](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122868.html)


## Improving the Process for Release Marketing
* Release marketing is a critical heart for sharing what's new in each release.
* Let's work together on reworking how the marketing community and projects work together to make the release communications happen.
* Having multiple, repetitive demands to summarize" top features" during release time can be a pester, and having to re-collect the information each time isn't an effective use of time.
    * Being asked to make a polished, "Press–Friendly" message out of release can feel too far outside of the PTL’s Focus areas or skills.
    * Technical content marketers, attempting to find the key features from release notes, mailing lists, specifications, roadmaps, whatever means interesting features are sometimes overlooked.
* To address this gap, the release team and foundation marketing team proposed collecting information as part of the release tagging process.
    * We will collect from deliverable files to provide highlights for the series (about three items).
    * The text will be used to build a landing page on release.openstack.org that shows the"Key features" flagged by PTL’s that the marketing teams should be looking at during release communication times.
        * This page will link to the [release notes](https://release.openstack.org) so marketers can gather additional information.
* [Message](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122678.html)


## Simplification in OpenStack
* Two camps appear: people that want to see OpenStack as a product with a way of doing deployments and the people who want to focus on configuration management tools.
    * One person gives an example of using both Ubuntu MAAS and Puppet. The puppet solution allowed for using existing deployment methodologies unlike the former.
* We should start promoting and using a single solution for the bulk of the community efforts. Right now we do that with Devstack as a reference implementation that nobody should use for anything but dev/test.
    * This sort of idea could make other deployment efforts relevant.
* Kolla came up at the PTG: scenario-based testing and documentation based on different  “constellations" or use cases.
    * Puppet has been doing [this](https://github.com/openstack/puppet-openstack-integration) and Triple-o has been doing [this](https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html).
    * If you break down actual use cases, most people want nova (qemu+KVM), neutron (vxlan, potentially VLAN), Cinder (ceph).
        * If we agreed to cover 90% of users, that'll boil down to 4 to 5 different “constellations.”
    * Someone has been working on a local testing environment, and it boils down to [this](https://github.com/test-kitchen/test-kitchen/issues/873).
* [Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122075)


-- 
Mike Perez
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/73173db0/attachment.sig>