-1 This is seriously dangerous idea: core-reviewer in fuel-qa does not mean exact skills for +2/W on fuel-octane, for example. Sometimes, because of limited time, reviewer will press +W without understanding patch detail. In repo, which he knows, he can fix issue later by itself, but only of he really knows what he doing.
пн, 5 сент. 2016 г., 19:14 Maksim Malchuk <mmalc...@mirantis.com>: > -1 > My vision - we should have something like super-core group with a smaller > number of the current core guys. > This is because a lot of current core guys were switched to the other > projects and already out of the scope. > Such guys still can be cores in their former projects and can help > sometimes, but only several guys can drive the Fuel. > > P.S. we always can nominate new cores to the specific project individually > if you don't like the super-core group idea. > > On Mon, Sep 5, 2016 at 6:39 PM, Andrew Maksimov <amaksi...@mirantis.com> > wrote: > >> +1 >> This is a good proposal, I also think we should have single fuel-core >> group for all repos. In real life core reviewers won't set +2 or merge to >> repos with which they are not familiar with. >> >> Regards, >> Andrey Maximov >> >> On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov < >> vkozhuka...@mirantis.com> wrote: >> >>> Dear colleagues, >>> >>> I'd like to suggest to use common fuel-core group for all Fuel projects >>> instead of having separate independent 'by-project' core groups like >>> 'fuel-astute-core' or 'fuel-agent-core'. >>> >>> Pros: >>> 1) It will be easier to access core members (timezone and holiday >>> tolerance) >>> 2) It will be easier to manage single core group (promote new members, >>> remove not active members) >>> >>> Cons: >>> 1) Less of flexibility. Permissions will be the same for all core >>> reviewers in all Fuel projects. >>> >>> What do you think? >>> >>> Vladimir Kozhukalov >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> > > > -- > Best Regards, > Maksim Malchuk, > Senior DevOps Engineer, > MOS: Product Engineering, > Mirantis, Inc > <vgor...@mirantis.com> > __________________________________________________________________________ > 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
