Two weeks ago, Russell Bryant inaugurated a series of blogposts about what the Technical Committee (“TC”) is working on. We will regularly post about the outcomes of the TC meetings, and rotate writers to give all TC members a chance to participate and describe what happens in their own words. This post will focus on what happened during the last two meetings.

The TC has several missions, and the topics we cover in TC meetings generally fall into one of them.

Mission #1: Integrated release contents

One of the missions of the TC is to determine what is part of the OpenStack “integrated release” that we collectively produce every 6 months. We manage the “incubation” process, through which selected projects can become part of the integrated release. We also keep an eye on already-integrated projects in case their scope evolves.

That’s the case currently for Glance, whose mission is evolving from cataloging and serving Nova disk images to cataloging and serving other artifacts consumed by other OpenStack services, like for example Heat templates. This scope evolution has been under discussion at the last two meetings. The principle of expanding Glance’s scope is pretty much accepted at this point, but the precise words to describe the new scope are still under discussion.

In order to set clear base expectations for projects in the incubation/integration process track, last cycle the TC came up with a reference document listing all the requirements for incubation, integration and the first integrated cycle that are consensual across TC members. This document is constantly revisited as we continue to raise the quality and convergence bar between integrated projects.

Last two meetings we have been discussing adding a translation support requirement for projects wishing to graduate from incubation. The main objection to it at this point is the lack of automated testing of the translated strings (which resulted in undetected I18N problems in the past). It looks like when this is addressed, this requirement will probably make it to the reference document.

Raising requirements for new entrants is one thing, but sometimes existing integrated projects do not fill those new requirements. This creates a gap that we need to address. During this cycle we reviewed most existing integrated projects (Heat and Swift are still pending). When a gap was raised, PTLs responded with a proposed “gap coverage plan” to address it.

The last project to go through that exercise was Glance, where a single gap around testing coverage was raised. Mark Washenberger (Glance PTL) created a gap coverage plan to address it and that plan was blessed by the TC at the last meeting.

Having plans is a good thing, but we also need to check that projects meet the deadlines that they set in such plans. Last week, after the juno-1 development milestone, we reviewed the progress on gap coverage plans. Ceilometer plan is on track, still targeting the juno-2 milestone for fully covering the gap. Horizon plan is mostly on track. Neutron has an ambitious gap coverage plan, and work on all gaps has started; gap 4 is a bit late (was planned to be completed by juno-1), but it’s also been determined to just be one API call. Trove plan is on track, and work started on all items.

Finally, having responsibility over the integrated release also means making sure we use terminology across integrated projects consistently. An issue was raised about the use of “certified” terminology to qualify CI testing on some projects. After open discussion on the -dev mailing-list and at the TC meeting, there was agreement that “certified” terminology was too loaded and should be phased out in favor of some variation around “tested”.

Mission #2: Representation of technical contributors

The TC is a directly-elected body representing all the technical contributors to the project. It is the final decision-making entity over technical matters in OpenStack as a whole. Some issues that can’t be solved at a lower level are sometimes escalated to the TC for final resolution, and the TC is also a convenient conduit for other OpenStack governance bodies to ask for general technical input.

Two issues were brought to the TC recently. The first one is about expected election behavior for our technical elections (PTLs and TC members). Our current election procedure doesn’t clearly describe expected behavior, and a proposal was raised to cover that. While everyone agrees on what is acceptable behavior and what is not, there are two ways of addressing issues if they arise. One is to piggy-back on the Community Code of Conduct, which clearly states that you should respect the election process. The other is to call out out-of-line behavior and trust the voters to make their own judgment about it. Both options are and will stay available, but we are still discussing which of those options (if any) we should encourage by making it part of the TC resolution. This discussion is on-going and will continue in a future meeting.

The other issue being brought to the TC were requests from the Foundation Board of Directors “Defcore” subcommittee for technical input to use as part of their work on trademark rules. There are two types of requested inputs. One is to provide for each project “designated sections” of code that you need to run in order to use the “OpenStack” trademark. The other is to give precise scoring for “core capabilities”: for each capability, indicate whether it’s part of the TC future direction or if it’s on its way to be deprecated.

While those inputs are technical (and we even voted on guidelines to help coming up with answers), some TC members expressed clearly their discomfort. Asking the representation of OpenStack contributors to designate parts of OpenStack that may just be replaced by proprietary alternatives (while still being called “OpenStack”) just crosses the line as to what they consider acceptable. Our “technical” answer might be read as an endorsement, or collaboration toward a behavior we don’t really want to encourage.

This tension has been surfacing every time Defcore was discussed at the TC meeting, and it’s difficult to address it between two topics in a one-hour online meeting. We have therefore scheduled a Defcore-specific TC meeting for July 1st (20:00 UTC in #openstack-meeting on Freenode IRC), and will try to clearly list concerns beforehand to ensure meeting clarity.