Open Stack

So again, nothing prevents a non-core security reviewer from reviewing blueprints and doing code reviews.  Believe me any security minded input is always welcome and weighed carefully.

Although the principle of having a minimum number of security reviewers in core is certainly a fair point of debate, in this particular case, the participation level does not warrant the outcry.  

Per http://russellbryant.net/openstack-stats/horizon-reviewers-365.txt

Reviews for the last 365 days in horizon
** -- horizon-core team member
+------------------------+------------------------------------------+---------------------+
|       Reviewer              | Reviews   -2  -1  +1  +2  +A    +/- %  | Disagreements* |
+------------------------+------------------------------------------+---------------------+
|   paul-mcmillan **   |                2    0    1    0     1     1     50.0% |    0 (  0.0%)             | 

As with other projects in OpenStack, removing a person from core merely implies that they are not actively reviewing enough to remain current with the code base and provide informed reviews with regards to the architecture and project direction.   Also in-line with other OpenStack projects, reviewers removed from core who begin providing regular and meaningful reviews will have a reduced period of time to be re-added to core.  Which I would be very happy to see.

David 

> -----Original Message-----
> From: Nathan Kinder [mailto:nkinder at redhat.com]
> Sent: Wednesday, December 11, 2013 9:33 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon] Nominations to Horizon Core
> 
> On 12/11/2013 08:08 PM, Bryan D. Payne wrote:
> >     We can involve people in security reviews without having them on the
> >     core review team.  They are separate concerns.
> >
> >
> > Yes, but those people can't ultimately approve the patch.  So you'd need
> > to have a security reviewer do their review, and then someone who isn't
> > a security person be able to offer the +1/+2 based on the opinion of the
> > security reviewer.  This doesn't make any sense to me.  You're involving
> > an extra person needlessly, and creating extra work.
> >
> >
> >
> >     This has been discussed quite a bit.  We can't handle security patches
> >     on gerrit right now while they are embargoed because we can't
> completely
> >     hide them.
> >
> >
> > I think that you're confusing security reviews of new code changes with
> > reviews of fixes to security problems.  In this part of my email, I'm
> > talking about the former.  These are not embargoed.  They are just the
> > everyday improvements to the system.  That is the best time to identify
> > and gate on security issues.  Without someone on core that can give a -2
> > when there's a problem, this will basically never happen.  Then we'll be
> > back to fixing a greater number of things as bugs.
> 
> +1.  I'd really like to see at least one security representative per
> project on core who makes sure that incoming code an blueprints are
> following security best practices.  These best practices still need to
> be clearly defined, but it's going to be impossible to uphold them once
> they are established unless someone with review power is involved.  We
> want security to be more proactive instead of reactive.
> 
> -NGK
> 
> >
> > -bryan
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev