Welcoming a common project for improving OpenStack user experience
We accepted a proposal for a new UX Program whose mission is to support and facilitate cross-project efforts to improve the overall user experience of OpenStack. I personally find this as exciting an effort and innovative as cross-project documentation in open source. Congratulations to this team and welcome! We look forward to great collaborative and open efforts across multiple projects.
Starter kit suggestions change
With much discussion the TC decided to change the compute starter kit tag applications slightly by adding the neutron project as the networking solution and removing the cinder project as a block storage solution since starter clouds could have ephemeral storage and then add block storage later.
New team for RPM packaging
A new team has been approved to manage all packaging git repos for RPM-based distributions in the /openstack git namespace. This team will enable gate testing and reviewing of changes
to the packaging close to the actual OpenStack development. The co-Project Team Leads are Dirk Mueller and Haikel Guemar. This team offers packaging for SUSE, openSUSE, Fedora Linux, Red Hat Enterprise Linux, or CentOS.
Stackforge resolution
Proceeding from our discussions about retiring Stackforge, we have continued to revise the resolution while still wanting to find a way to alleviate the extra work of organization renaming. The current proposal is instead of retiring the Stackforge project, we simply move all Stackforge projects into the “openstack/” namespace and create new projects there as well. Then as projects become official OpenStack projects, no repository renames are necessary. Essentially, this means the “openstack/” namespace will no longer hold only official OpenStack projects, but also any project being developed in our community-driven shared development environment. This should be a lot less disruptive to developers, users, and system administrators.
M naming quest resolved
The M release is Mitaka, say it three times fast! Mitaka, mitaka, mitaka. And if you can write the second character in the name, 三鷹, color me impressed!
Service names and project names
In an insane quest for consistency and ability to write about each service in a sensible way, TC member and documentarian Anne Gentle has proposed a set of guidelines for projects and services names, even for those services that have been around a few years. After consulting with the legal team and technical editors alike, please review the proposed guidelines and take a look at examples of possible new names with the new guidelines applied:
- Object Storage -> Object storage
- Block Storage -> Block storage
- Image service-> Image
- Database service -> Database
- Bare metal service -> Bare metal
- Key-Value Store as a Service -> Key value storage
- Message Broker Service -> Message broker
Please take a look and comment on the reviews so we can discuss and look at various examples.
Introducing deliverables defined across repositories
We have discovered during testing across projects that often deliverables we produce
as a single “thing” may be represented by multiple code repositories. For example, a Networking release from the neutron team is actually made of openstack/neutron and openstack/neutron-lbaas and other gatherings from neutron-*aas. A release from the “sahara” team for the Data processing service is actually made of openstack/sahara, openstack/sahara-extra and openstack/sahara-image-elements. Those repositories are all released at the same time with the same version number, and published together as a single “deliverable”. We want to ensure that the projects.yaml file indicates
the collection. It makes also sense to apply the “tags” we define at that user-visible layer, rather than at the (technical) git repository layer.
Leave a Reply