Yep I totally agree that adding cores for the sake of adding cores doesn’t make 
sense. Just trying to fish for ideas to prevent having to go to a single +2 to 
merge as that does make me nervous. But I guess for the sake of moving code 
through it needs to be done at the moment.


> On 1 Mar 2017, at 11:53, Rob Cresswell <robert.cressw...@outlook.com> wrote:
> 
> Adding inexperienced cores doesn't really alleviate that issue though, and I 
> don't currently feel that there is anyone with the right balance of 
> experience and activity to be added to the core team.
> 
> Me and Richard monitor review activity very closely though, and we are 
> actively looking to grow the team. We just need more activity from reviewers 
> so that they can learn, and in turn we can teach them. I don't expect people 
> to know everything before being core - I certainly didn't - but I don't think 
> the bar is being met just yet.
> 
> Rob
> 
> On 1 March 2017 at 10:36, Beth Elwell <beth.openst...@gmail.com 
> <mailto:beth.openst...@gmail.com>> wrote:
> Has there been any consideration of growing the core team to help with review 
> bandwidth? I ask only because that resulting responsibility to the community 
> can drive additional review activity. Just worried that only 1x +2 could 
> cause issues with code being  merged on a project this large that could 
> potentially break things or clash with other opinions or standards of how it 
> should be written/implemented? It concerns me that it makes it easier to 
> overlook larger things in more substantial patches. I guess as you say, there 
> needs to be accountability re not always going for the single +2 when the 
> patch is of that sort of size and you need a second opinion?
> 
> Beth
> 
> > On 28 Feb 2017, at 10:09, Rob Cresswell <robert.cressw...@outlook.com 
> > <mailto:robert.cressw...@outlook.com>> wrote:
> >
> > Hey everyone,
> >
> > Horizon is moving to requiring only a single core review for code approval. 
> > Note that cores are not obliged to approve on a single +2; if a core would 
> > like a second opinion for patches that are complex or high risk, that is 
> > also fine.
> >
> > We still require at least one of the core reviewers or contributor on a 
> > patch to be from separate companies however. For example, if a patch is 
> > authored by someone from Cisco, then I could not (as a Cisco employee) +2+w 
> > the patch by myself; it would require at least another core +2.
> >
> > This should help us move smaller patches along quicker.
> >
> > Rob
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __________________________________________________________________________
> 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

__________________________________________________________________________
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

Reply via email to