Sometimes producing alternate implementations can be more effective than
abstract discussions because they are more concrete. If an implementation can
be produced (possibly multiple different implementations by different
contributors) in a short period of time without significant effort, that’s
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
If we see from the angle of the contributor whose approach would not be
better than other competing one, it will be far easy for him to accept
logic at discussion stage rather after weeks of tracking review request and
addressing review comments.
On 5 Nov 2015 08:24, "Vikas Choudhary"
On Wed, Nov 4, 2015 at 2:38 PM, Baohua Yang 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
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 <
> On Wed, Nov 4, 2015 at 2:38 PM, Baohua Yang wrote:
>> +1, Antoni!
>> btw, is our
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
btw, is our weekly meeting still on meeting-4 channel?
Not found it there yesterday.
On Wed, Nov 4, 2015 at 9:27 PM, Antoni Segura Puimedon <
> Hi Kuryrs,
> Last Friday, as part of the contributors meetup, we discussed also code