<div dir="ltr"><div><div><div>Hi,<br><br><br></div><div>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.<br><br></div><div>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):<br></div><div>14:00-1800 UTC Thurs (Staring 7th July - not available the 14th hence suggesting this Thurs)<br>14:00-1800 UTC Tues (Staring 12th July)<br></div><div><br></div><div>I'm assuming that later in the day for me aligns better with others, but I could be very wrong.<br></div><div><br></div><div>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.<br><br><br></div><div><br></div><div>More info below on why suggest this:<br></div><div><br><br></div>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.<br><br></div><div>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:<br><ul><li>Take a long time complete the cycle of rework -> review -> rework -> break -> rework ->. ...</li><li>Block landing any changes that touch any of the code impacted by V2 work until most V2 patches are landed.<br></li></ul></div><div></div><div><br><br></div>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.<br></div><div><br></div>Expect that this would only take 3-4 of these to get the major part of the rewrite in place.<br><div><div><div><div><br></div><div>Thoughts? Does this work for enough other JJB reviewers?<br><br clear="all"><div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Darragh Bailey<br>"Nothing is foolproof to a sufficiently talented fool"</div>
</div></div></div></div></div></div>