Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of all open topics (updated twice a week) at:
https://wiki.openstack.org/wiki/Technical_Committee_Tracker If you are working on something (or plan to work on something) governance-related that is not reflected on the tracker yet, please feel free to add to it ! == Recently-approved changes == * Add PowerStackers project team [1] * Add resolution about CI for external projects [2] * Add naming poll info for S release [3] * Fix small oversight in Python PTI for tests [4] * Goal updates: glance * New repos: openstack-ansible-nspawn_hosts, openstack-ansible-nspawn_container_create, puppet-monasca, openstack-ansible-os_panko, rally-openstack, ansible-role-redhat-subscription * Removed repo: horizon-cisco-ui [1] https://review.openstack.org/540165 [2] https://review.openstack.org/545065 [3] https://review.openstack.org/545010 [4] https://review.openstack.org/545639 Major news here is the final approval of the PowerStackers project team, dedicated to providing OpenStack support for the POWER CPU architecture: https://governance.openstack.org/tc/reference/projects/powerstackers.html The Technical Committee also approved a resolution to define acceptable usage of OpenStack CI resources to the testing of other projects: https://governance.openstack.org/tc/resolutions/20180215-third-party-check.html == TC track at the PTG == We held a track on Friday at the PTG to discuss Technical Committee initiatives and more generally OpenStack-wide and governance issues. Here is a quick summary of what happened there. We started with a retrospective of how we got things done so far with this membership. Async collaborations worked well, and the weekly reports were seen as helpful. We should probably try to steer the topic of discussions in office hours a bit more. We also need to more consciously track progress on TC initiatives, with something to stand between the vision and the individual changes posted to implement it. Using a task tracker (StoryBoard) was suggested. We should also make sure to have more than one member on the TC being able to apply approval rules on the governance repository, so that the chair does not block everything while they take time off. After that we reviewed progress against the vision. Most progress has been made on the "engaging with adjacent communities" front. Constellations are still waiting for their first practical application. Dims volunteered to drive one around containers. Situation on the diversity front has been improving, although we could always do better. We should encourage everyone to push people they see as great candidates to run. As far as growing new leaders goes, we had some success getting new people to step up and champion goals. We need to encourage those (thanks email from Foundation, success story articles). Next topic was reviewing community goals, and how to improve the selection process and wider community engagement around them, as well as how to provide more active support to those who step up to champion them. From there we switched to discussing base services. The addition of etcd to the OpenStack base services did not exactly trigger wide adoption of it yet, for various reasons. We discussed various ways to make it finally pass that critical mass that would make everyone more comfortable leveraging it. Then we switched to reviewing the concept of maintenance mode and our usage of team diversity tags. Maintenance mode was still seen as a useful status to communicate to consumers of OpenStack, and we discussed ways to sustainably maintain "stable" projects over the long run. The team diversity tags, on the other hand, were designed with metrics that fit the 2014 growth pattern, but are not so great in a landscape with more stable components maintained by smaller teams. We might want to replace them with regular (qualitative rather than quantitative) organizational diversity reports that would provide better insights. Final topic of the morning was the Python 2 deprecation process, with next-gen operating systems more and more likely to drop Py2 earlier rather than later. We discussed the current state of the transition and decided to come up with a clearer timeline (some mentioned the need for all of OpenStack to support Python 3 by the T release, Q3 2019). On the afternoon we discussed the resolution about stable branch EOL and "extended maintenance" that was discussed earlier in the week. In particular we discussed the ability for project stable maint teams to retain control over their stable maint story, and avoid having two completely separate teams producing the same component. The discussion on this continued on the review (see below). Then we discussed the tc-approved-release tag. It's a technical tag used to communicate to the board the set of projects that we are fine with them potentially including in trademark programs. However the name of the tag makes people read too much into it, and makes it difficult to remove things from it. Creating a new tag more specifically around trademark program admissibility might be a way to fix it. From there the discussion moved to discuss the Interop tests location issue (more on that below). Before our brains turned into complete mush, we also discussed the impact on OpenStack of the OpenStack Foundation support to new strategic focus areas. It creates an opportunity to focus OpenStack on the open cloud infrastructure use case (calling other by-products like our CI/CD system under its own name). However we need to proactively engage with other technical leaders in those areas (like the Kata Containers Arch committee) in order to paint a good complementarity story. For more details, you can find detailed notes on the following etherpad: https://etherpad.openstack.org/p/PTG-Dublin-TC-topics == Under discussion == The PTG rebooted the discussion to clarify how the testing of interoperability programs should be organized in the age of add-on trademark programs. During the TC track there was a new strawman proposal (with agreement from some InteropWG, some QA, some Heat and and Designate team members present) to have interop-specific Tempest plugins co-owned by QA/Interop/add-on project team. mugsie amended his proposal accordingly: https://review.openstack.org/#/c/521602/ cdent did post his own simplified variant of the same strawman: https://review.openstack.org/#/c/550571/ An alternative solution is to just say that the InteropWG should be able to pick tests wherever they see fit. The environment has changed over the past 4 years, so strong guidance from the TC as to where to find tests might no longer be needed. mugsie posted this alternate option as: https://review.openstack.org/#/c/550863/ The other hot topic under discussion is mriedem's resolution defining "extended maintenance", as a result of the discussions on Tuesday afternoon's "release cycles vs. downstream consumption models" track. This resolution is trying to strike the right trade-off between encouraging new resources to step up to maintain branches for a longer period of time, avoiding schisms between project stable maint teams and new extended maintenance resources, the need for a common understanding of what we mean by stable branches (no feature backport) and making sure we still test things and do not introduce regressions. Please comment at: https://review.openstack.org/#/c/548916/ == TC member actions for the coming week(s) == We should establish an etherpad to discuss potential Forum sessions we'd like to file for the Vancouver Summit. == Office hours == To be more inclusive of all timezones and more mindful of people for which English is not the primary language, the Technical Committee dropped its dependency on weekly meetings. So that you can still get hold of TC members on IRC, we instituted a series of office hours on #openstack-tc: * 09:00 UTC on Tuesdays * 01:00 UTC on Wednesdays * 15:00 UTC on Thursdays For the coming week, I expect discussions to be around the Interop test location resolution(s) and the Extended maintenance proposal. Cheers, -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev