Open Stack

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.cresswell at 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.openstack at gmail.com <mailto:beth.openstack at 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.cresswell at outlook.com <mailto:robert.cresswell at 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-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170301/2272cd53/attachment.html>