Open Stack

HI Darragh,

I would like to help where I can in the reviews, but Tuesdays and Thursdays
are my busiest days. I can only guarantee that I am free after 19:00 UTC on
Tuesdays and Thursdays. Monday and Fridays are days where I am free from
summer class obligations but I am not too sure if that will work with
everyone else.

Regards,
Kien Ha

On Mon, Jul 4, 2016 at 8:47 PM, Dong Ma <winterma.dong at gmail.com> wrote:

> Hey Darragh,
>
>
>
> I agree with your thought and would like to participate to the reviews,
> although the time slots is a little late for me but it works.
>
>
>
> Thanks,
>
> Dong Ma (Vincent)
>
>
>
> Email: winterma.dong at gmail.com
>
> IRC: larainema
>
> Telephone: +86 18610023880
>
>
>
>
> 2016-07-05 0:43 GMT+08:00 Darragh Bailey <daragh.bailey at gmail.com>:
>
>> Hi,
>>
>>
>> To try and minimise trashing of both core reviews and V2.0 patch
>> author(s), I'd like to propose that we pick a time/day every second week
>> for 3-4 iterations where those interested set aside a set block of time to
>> collaborate in getting the main rework patches landed. Consider it a set of
>> mini bug days focused on JJB 2.0 API changes.
>>
>> To get the ball rolling, I'm going to suggest one of the following 2
>> timezones (obviously these suit me best, but I'm available the other days
>> as well):
>> 14:00-1800 UTC Thurs (Staring 7th July - not available the 14th hence
>> suggesting this Thurs)
>> 14:00-1800 UTC Tues (Staring 12th July)
>>
>> I'm assuming that later in the day for me aligns better with others, but
>> I could be very wrong.
>>
>> Also thinking that spinning up a temporary public dedicated IRC chat room
>> would be helpful here, probably look to avoid using one of the existing
>> meeting rooms because I'm assuming that would conflict with other teams,
>> unless someone tells me there is a simple solution to this. Only negative I
>> can see is that the chats wouldn't be logged.
>>
>>
>>
>> More info below on why suggest this:
>>
>>
>> Having gone through a few cycles where patches get reviewed, reworked and
>> then broken by other changes landing, reworked again, reviewed and broken
>> again, it can be quite onerous on both author and reviewer getting a change
>> that touches a number of places to land as the risk of another patch
>> landing causing a merge failure increases dramatically the more places the
>> patch touches.
>>
>> The set of V2 patches has to bring the existing code through some amount
>> of interim steps to make it easy to review, unfortunately given the amount
>> of rework to do, the odds of anything else triggering a conflict is pretty
>> high and basically faced with the following choices:
>>
>>    - Take a long time complete the cycle of rework -> review -> rework
>>    -> break -> rework ->. ...
>>    - Block landing any changes that touch any of the code impacted by V2
>>    work until most V2 patches are landed.
>>
>>
>>
>> However we can get enough cores on around the same time and try for some
>> synchronized collaboration, I think it's probably far easier to land a
>> series of patches over a few meetings and get everything far enough along
>> with much less workload placed on everyone involved that we can then revert
>> back to the more async approach without the same issues around the
>> remaining changes.
>>
>> Expect that this would only take 3-4 of these to get the major part of
>> the rewrite in place.
>>
>> Thoughts? Does this work for enough other JJB reviewers?
>>
>>
>> --
>> Darragh Bailey
>> "Nothing is foolproof to a sufficiently talented fool"
>>
>> _______________________________________________
>> OpenStack-Infra mailing list
>> OpenStack-Infra at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160705/e0a01bfe/attachment-0001.html>