[Starlingx-discuss] Cross checking projects and repos

[Saul Wold]

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 at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
>