Open Stack

-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 <mmalchuk at 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 <amaksimov at 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 <
>> vkozhukalov at 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-request at 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-request at 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
> <vgordon at mirantis.com>
> __________________________________________________________________________
> 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/20160905/7a4680b5/attachment.html>