These were deprecated shortly after the project was launched. * Gplv2 - Not listed * Gplv3 - Not listed * Utils - Not listed Brent.... From: Jones, Bruce E [mailto:bruce.e.jones@intel.com] Sent: Thursday, October 17, 2019 5:30 PM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Cross checking projects and repos TL;DR We have repos that are not listed in the projects.yaml file used for generating eligible voters. We have projects with a one-to-many relationship to repos, some of which are not part of StarlingX, which makes running scripts to find eligible voters a problem. We should fix both issues. As the (soon to be former) PL of the Openstack-distro project, and as one of the election officials, I've been busy the last few weeks trying to get my arms around figuring out who the eligible voters are for the project. Sadly, it's not as easy as it could be. The Openstack-distro project doesn't own any repos, instead the team contributes to repos owned by other projects. I thought I'd take a look at the similar projects see what the mapping of repos to projects looks like overall. I mapped our repos to projects using the projects.yaml file in the governance repo. The following starlingX repos are _not_ listed in projects.yaml by any sub-project: * Election - Cores are the Election officials, likely OK * Governance - Cores are the TSC, likely OK * Gplv2 - Not listed * Gplv3 - Not listed * Specs - Cores are the TSC, likely OK * Tis-repo - Not listed * Upstream - Not listed * Utils - Not listed Question: Are the repos shown as "Not listed" above still used? Should we add them to the projects.yaml file? If so, where? I then thought I'd take a look at the 3 projects that do not own any repos. I went through the project's Etherpads and looked at the reviews shown in them, to see where the code contributed by the team landed. Here is what I found: * Multi-OS - Contributed to ha, nfv, fault, metal, specs, config (expecting more as the project moves forward) * Networking - Contributed to monitoring, openstack-helm, specs, integ, config, openstack/neutron, openstack/neutron-specs, upstream, openstack/neutron-lib, openstack/neutron-tempest-plugin, openstack/python-openstackclient, openstack/openstacksdk * Openstack-distro - Contributed to openstack-armada-app, upstream, tools, root, openstack/python-openstackclient, openstack/nova, openstack/openstack-helm, openstack/python-novaclient, integ For most of our projects, we can generate the eligible voters by simply querying the repos. For Multi-OS, Networking and OpenStack-distro, that approach doesn't work and the PLs have to keep track of who commits on behalf of the project. I think that approach is far from ideal and would like to open a discussion about what we can do to help these PLs solve this problem for the next election. brucej