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