Developer Mailing List Digest September 23-29 2017

giantpanda

Summaries

Sydney Forum

General Links

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:

Etherpads from Teams and Working Groups

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 a local testing environment, and it boils down to this.
Thread