Open Stack

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