[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
See comments about the repo list, we can drop 4 of them for sure. On 10/17/19 2:30 PM, Jones, Bruce E wrote:
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
Not used any more, likely OK
·Specs - Cores are the TSC, likely OK
·Tis-repo - Not listed
Also not used
·Upstream - Not listed
This should be part of the Openstack Team
·Utils - Not listed
Not used.
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
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
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
On 10/17/19 4:30 PM, Jones, Bruce E wrote:
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:
* Gplv2 - Not listed * Gplv3 - Not listed * Tis-repo - Not listed * Utils - Not listed
These were in the original set and recombined into the flock repos soon after the initial public release. They remain in Gerrit because history. *(Actually tis-repo was never used by StarlingX, I have used it for running test jobs such as the github-based stx-nova unit and functional tests for our stable branch fork.)
* Upstream - Not listed
Saul mentions below and I agree this actually is a repo for the OpenStack Distro team as that is what is in it. It should be added and its contributors checked.
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.
PLs have the responsibility to track the Extra-ATCs already, that is essentially what this is when a team does not have a repo. In the end it is the team leadership (TL, PL, cores) who know who is making contributions to the goals of the team. The PL can always delegate that task to anyone they choose. The alternatives that I have thought about all require _someone_ to do more work, whether it is a team leader or the contributors themselves. Asking the contributors to do something to actively register their interest/participation would help with collecting an initial list but someone will still have to evaluate if I can get added to an electorate just by registering and lurking in the team meetings. (I wouldn't count that as a contribution.) So create a wiki page (it requires a login so can be somewhat trusted as to who is doing the editing) and ask contributors to add themselves to it to produce that initial list. Then the PL only needs to confirm foundation membership and evaluate the contribution that was made by the individuals. Or to go one step closer to what was suggested in the TSC meeting, ask the contributors to create a review adding themselves to extra-atcs and the team can +1 that for those they consider to have made sufficient contributions. dt -- Dean Troyer dtroyer@gmail.com
On 2019-10-17 17:30:49 -0500 (-0500), Dean Troyer wrote:
On 10/17/19 4:30 PM, Jones, Bruce E wrote:
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:
* Gplv2 - Not listed * Gplv3 - Not listed * Tis-repo - Not listed * Utils - Not listed
These were in the original set and recombined into the flock repos soon after the initial public release. They remain in Gerrit because history. *(Actually tis-repo was never used by StarlingX, I have used it for running test jobs such as the github-based stx-nova unit and functional tests for our stable branch fork.) [...]
You might consider checking out the way OpenStack solved a similar tracking problem: https://opendev.org/openstack/governance/raw/branch/master/reference/legacy.... Basically create a shadow of projects.yaml where you move or record entries for repositories (and even entire teams) which were at one time official but no longer are, including information on when they ceased being in use and were retired. If you follow the same schema OpenStack does, the existing election tools can even evaluate contributions to repositories which were retired after the start of the qualifying window for an election (if any were still official for part of that time). -- Jeremy Stanley
participants (5)
-
Dean Troyer
-
Jeremy Stanley
-
Jones, Bruce E
-
Rowsell, Brent
-
Saul Wold