Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160705/de42a206/attachment.html>