Re: [OpenStack-Infra] JJB V2.0 planning
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 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: winterma.d...@gmail.com > > IRC: larainema > > Telephone: +86 18610023880 > > > > > 2016-07-05 0:43 GMT+08:00 Darragh Bailey : > >> 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 > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] JJB V2.0 planning
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 : > 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
[OpenStack-Infra] JJB V2.0 planning
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] [Infra] Meeting Tuesday July 5th at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday July 5th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting Anyone is welcome to to add agenda items and everyone interested in the project infrastructure and process surrounding automated testing and deployment is encouraged to attend. In case you missed it or would like a refresher, the meeting minutes and full logs from our last meeting are available: Minutes: http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-28-19.03.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-28-19.03.txt Log: http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-06-28-19.03.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra