Open Stack

On Mon, Jul 04, 2016 at 05:43:14PM +0100, Darragh Bailey wrote:
> 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.
> 
You may want to check if the #openstack-sprint channel is available on freenode.
We have logging enabled on it and seems like a natural fit for your agenda.

> 
> 
> 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