Developer Mailing List Digest September 23-29 2017

The content below is taken from the original (Developer Mailing List Digest September 23-29 2017), to continue reading please visit the site. Remember to respect the Author & Copyright.

Summaries

• TC Report 39
• Release countdown for week R-21, September 29 – October 6
• Technical committee status update, September 29
• Placement/resource providers update 36
• POST /api-sig/news

Sydney Forum

General Links

• What the heck is the form?
• When: November 6-8, 2017
• Where: OpenStack Summit in Sydney Australia
• Register for The OpenStack Sydney Summit and show up!
• Deadline for topic sessions was September 29th UTC by this submission form.
• All Sydney Forum etherpads

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
• User Committee Catch-all

Etherpads from Teams and Working Groups

• Nova
• Cinder
• Ops Meetups Team
• OpenStack Ansible
• Self-healing SIG
• Neutron Quality-Of-Service Discussion
• QA Team
• Watcher
• SIG K8s
• Kolla

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

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

Improving the Process for Release Marketing

• Release marketing is a critical heart for sharing what’s new with 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 recollect 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 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 so marketers can gather additional information.
• Message

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 and Triple-o has been doing this.
  • 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 making up and start work at a local testing environment, and it boils down to this.
• Thread