@Toni ,

In scenarios where two developers, with different implementation
approaches, are not able to reach any consensus over gerrit or ml, IMO,
other core members can do a voting or discussion and then PTL should take a
call which one to accept and allow for implementation. Anyways community
has to make a call even after implementations, so why to unnecessary waste
effort in implementation.
WDYT?
On 4 Nov 2015 19:35, "Baohua Yang" <yangbao...@gmail.com> wrote:

> Sure, thanks!
> And suggest add the time and channel information at the kuryr wiki page.
>
>
> On Wed, Nov 4, 2015 at 9:45 PM, Antoni Segura Puimedon <
> toni+openstac...@midokura.com> wrote:
>
>>
>>
>> On Wed, Nov 4, 2015 at 2:38 PM, Baohua Yang <yangbao...@gmail.com> wrote:
>>
>>> +1, Antoni!
>>> btw, is our weekly meeting still on meeting-4 channel?
>>> Not found it there yesterday.
>>>
>>
>> Yes, it is still on openstack-meeting-4, but this week we skipped it,
>> since some of us were
>> traveling and we already held the meeting on Friday. Next Monday it will
>> be held as usual
>> and the following week we start alternating (we have yet to get a room
>> for that one).
>>
>>>
>>> On Wed, Nov 4, 2015 at 9:27 PM, Antoni Segura Puimedon <
>>> toni+openstac...@midokura.com> wrote:
>>>
>>>> Hi Kuryrs,
>>>>
>>>> Last Friday, as part of the contributors meetup, we discussed also code
>>>> contribution etiquette. Like other OpenStack project (Magnum comes to
>>>> mind), the etiquette for what to do when there is disagreement in the way
>>>> to code a blueprint of fix a bug is as follows:
>>>>
>>>> 1.- Try to reach out so that the original implementation gets closer to
>>>> a compromise by having the discussion in gerrit (and Mailing list if it
>>>> requires a wider range of arguments).
>>>> 2.- If a compromise can't be reached, feel free to make a separate
>>>> implementation arguing well its difference, virtues and comparative
>>>> disadvantages. We trust the whole community of reviewers to be able to
>>>> judge which is the best implementation and I expect that often the
>>>> reviewers will steer both submissions closer than they originally were.
>>>> 3.- If both competing implementations get the necessary support, the
>>>> core reviewers will take a specific decision on which to take based on
>>>> technical merit. Important factor are:
>>>>     * conciseness,
>>>>     * simplicity,
>>>>     * loose coupling,
>>>>     * logging and error reporting,
>>>>     * test coverage,
>>>>     * extensibility (when an immediate pending and blueprinted feature
>>>> can better be built on top of it).
>>>>     * documentation,
>>>>     * performance.
>>>>
>>>> It is important to remember that technical disagreement is a healthy
>>>> thing and should be tackled with civility. If we follow the rules above, it
>>>> will lead to a healthier project and a more friendly community in which
>>>> everybody can propose their vision with equal standing. Of course,
>>>> sometimes there may be a feeling of duplicity, but even in the case where
>>>> one's solution it is not selected (and I can assure you I've been there and
>>>> know how it can feel awkward) it usually still enriches the discussion and
>>>> constitutes a contribution that improves the project.
>>>>
>>>> Regards,
>>>>
>>>> Toni
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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 wishes!
>>> Baohua
>>>
>>>
>>> __________________________________________________________________________
>>> 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 wishes!
> Baohua
>
> __________________________________________________________________________
> 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