@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