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
