Open Stack

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)