[openstack-dev] [kuryr] competing implementations

Baohua Yang yangbaohua at gmail.com
Wed Nov 4 14:04:30 UTC 2015


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+openstackml at midokura.com> wrote:

>
>
> On Wed, Nov 4, 2015 at 2:38 PM, Baohua Yang <yangbaohua at 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+openstackml at 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-request at 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-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 wishes!
Baohua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151104/8329fe2f/attachment.html>


More information about the OpenStack-dev mailing list