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.d...@gmail.com IRC: larainema Telephone: +86 18610023880 2016-07-05 0:43 GMT+08:00 Darragh Bailey <daragh.bai...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > >
_______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra