Re: [OpenStack-Infra] JJB V2.0 planning

[Kien Ha]

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

[Dong Ma]

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

[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] [Infra] Meeting Tuesday July 5th at 19:00 UTC

[Elizabeth K. Joseph]

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