Some out-of-context quotes and comments below: Jeremy Stanley wrote: > [...] > 1. Since the vulnerability:managed governance tag applies to > deliverables, all repos within a given deliverable must meet the > qualifying criteria. This means that if some repos in a deliverable > are in good enough shape to qualify, their vulnerability management > could be held back by other repos in the same deliverable. It might > be argued that perhaps this makes them separate deliverables (in > which case the governance projects.yaml should get an update to > reflect that), or maybe that we really have a use case for per-repo > tags and that the TC needs to consider deliverable and repo tags as > separate ideas.
If repositories forming a single deliverable have varying degrees of maturity or support and that cannot be fixed quickly, then yes I would argue that they do not form a coherent whole and need to be split into a separate deliverable. The idea behind applying tags to deliverables is to facilitate splitting a given user-consumable product (deliverable) across multiple git repositories. They should still make a coherent whole and have common characteristics, otherwise they are not a single user-consumable product, they are a bunch of repositories with various levels of quality and support, thrown together for dubious reasons. So if for example we can't apply the same tags to openstack/neutron and openstack/neutron-*aas, then the *aas should probably form a separate deliverable (called for example "neutron advanced services"). > [...] > 5. The deliverable's repos should undergo a third-party review/audit > looking for obvious signs of insecure design or risky implementation > which could imply a large number of future vulnerability reports. As > much as anything this is a measure to keep the VMT's workload down, > since it is by necessity a group of constrained size and some of its > processes simply can't be scaled safely. It's not been identified > who would actually perform this review, though this is one place > members of the OpenStack Security project-team might volunteer to > provide their expertise and assistance. About that one, one of the reasons we tried to have the projects audited before inclusion was to avoid to issue a dozen OSSAs the first time a project goes through a static code checker. So it is also about proactively clearing the obvious stuff before it generates a spike in VMT work. -- 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