Open Stack

Thanks you Jeremy for starting this discussion :-)

Proposed criteria works for me and they concurs with what have been
discussed in Vancouver.

My comments on the open-question below.


On 09/01/2015 06:56 PM, Jeremy Stanley wrote:
> A. Can the VMT accept deliverables in any programming language?

Any supported programming language by the openstack project should/could
also be accepted for vulnerability management.
As long as there is a way to test patch, I think the VMT can support
other languages like Go or Puppet.


> 
> B. As we expand the VMT's ring within the Big Top to encircle more
> and varied acts, are there parts of our current process we need to
> reevaluate for better fit? For example, right now we have one list
> of downstream stakeholders (primarily Linux distros and large public
> providers) we notify of upcoming coordinated disclosures, but as the
> list grows longer and the kinds of deliverables we support becomes
> more diverse some of them can have different downstream communities
> and so a single contact list may no longer make sense.
> 
The risk is to divide downstream communities, and managing different
lists sounds like overkill for now. One improvement would be to maintain
that list publicly like xen do for their pre-disclosure list:
  http://www.xenproject.org/security-policy.html


> C. Should we be considering a different VMT configuration entirely,
> to better service some under-represented subsets of the OpenStack
> community? Perhaps multiple VMTs with different specialties or a
> tiered structure with focused subteams.
> 
> D. Are there other improvements we can make so that our
> recommendations and processes are more consumable by other groups
> within OpenStack, further distributing the workload or making it
> more self-service (perhaps reducing the need for direct VMT
> oversight in more situations)?
> -- Jeremy Stanley

With a public stakeholder list, we can clarify our vmt-process to be
directly usable without vmt supervision.

Anyway, imo the five criteria proposed are good to be amended to the
vulnerability:managed tag documentation.

Again, thank you fungi :-)
Tristan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150902/9f8b728b/attachment.pgp>