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

[Darragh Bailey]

Think you forgot to Reply-All ;-)

Only spotted that now, while I was waiting for others to chime in and see
different points of view.

On 22 November 2016 at 07:25, Wayne Warren  wrote:

>
>
> On Tue, Nov 15, 2016 at 8:04 AM, Darragh Bailey 
> wrote:
>
>>
>> So on that patch:
>> https://review.openstack.org/358019 Support explicit API and simple
>> config creation
>>
>> Does it make sense? I'd like to hear other people's opinion on whether it
>> makes sense to have an explicit API as well as a from_config(cfg) method
>> when someone would create the config object and then pass it around, or is
>> it more of a YAGNI?
>>
>
> I think that if you don't have an explicit use case for it that you intend
> to use personally it's probably a YAGNI.
>
> Personally, I prefer to pass configuration values around with and access
> them through an instance of a single configuration class that
>
> * can be more easily instantiated with reasonable default settings
> * we can reason about and write tests for configuration
> * discourages proliferation of scattered configuration value munging
> throughout the code base which is one problem that JJBConfig was intended
> to address
>
> Also, should all classes be instantiable without a JJBConfig? Why? If not,
> why not? I'm curious why the focus on the Builder object for this behavior,
> but I'm also interested in the principles at work here so I can change my
> way of thinking if it's flawed; sorry if I've missed an explanation in the
> past.
>

Previous experience with libcurl, which also uses this idea of
configuration all in one object and then passed around, resulted in me
experiencing that fun behaviour of needing to refer back to the config
object in order to determine how to control the behaviour of the other
API's I was calling. It was exceedingly frustrating, though that might be
just due to poor API documentation on the curl project's behalf.

I'm not sure it'll discourage "proliferation of scattered configuration",
but rather have methods that reach into the config object to get
behavioural controlling settings that are not then clearly reflected in the
arguments into the method/class.

End up needing to define config options used internally as part of
classes/methods docstrings in order to help convey how to use the API.

Btw, the builder was just the easiest to look at first, I didn't see any
point in going through the rest of the objects and making changes to have
an expressive constructor which used params that controlled the current
objects behaviour, if it was clear this doesn't make sense as an approach.

Of course for the plugin settings, these will have to be passed through as
a single config object to the dispatch methods, so perhaps unless we plan
to look at that as well, maybe there is no need to worry about the other
classes having separate params for each setting controlling instantiated
objects behaviour.



> Since it impacts the API that will be published, seems like it would be a
>> good idea to get this ironed out before releasing?
>>
>
> I'd prefer to choose one approach for instantiating objects now based on
> its technical merits, make sure it's not incompatible with whatever
> alternative we are considering, and save alternatives as additive features
> that can be implemented sometime in the future when a need becomes apparent.
>

Agreed, it's probably only because there is no overloading of constructors
available in most dynamic languages that it's needing a closer look because
I'm not sure it's possible to add support for creation without a config
object without another breaking API change. I think the only solution would
be simple subclasses with different __init__ methods.

Hence I'm willing to look at this pretty closely.


> --
>> Darragh Bailey
>> "Nothing is foolproof to a sufficiently talented fool"
>>
>
>

Suggested to Thanh, that it might be worth cutting a beta release (maybe
tomorrow) and advertise it to allow people to start installing from pypi by
using '--pre'.

-- 
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

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

[Darragh Bailey]

(Starting a second reply for a different patch to make it easier to follow
with threaded mail clients)

I've a comment in
https://review.openstack.org/#/c/319616/8/jenkins_jobs/builder.py that
notes if an application made a call to 'JenkinsManager.update_jobs()' it
would be a reasonable expectation that a subsequent call to
'JenkinsManager.delete_old_managed()' should not need to explicitly be
passed the list of jobs that were just to the update method.

For simplicity does it make sense to ensure the following would do the
right thing by default:

jm = JenkinsManager(cfg)
jm.update_jobs([list of jobs])
jm.delete_old_unmanaged()

This would require maintaining some internal state in JenkinsManager on the
list of jobs updated and then reusing that list in delete_old_unmanaged()
unless passed an explicit list of jobs to keep.

If this were to be supported, should it take the form of:

   1. Retain the list of the last set of jobs sent to update_jobs(), and
   overwrite on each call to update_jobs()
   2. Continuously update an internal list of jobs of what has been updated
   since the JenkinsManager object was created?


The second one would facilitate multiple calls to update_jobs, but tbh I
suspect it's unnecessary complicated. But thought I'd throw it out there.
At the very least I'm going to fix the method so that a call without
passing a list of jobs doesn't cause an exception.

-- 
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

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

[Darragh Bailey]

Hi,

On 11 November 2016 at 14:59, Thanh Ha  wrote:

> On Thu, Nov 10, 2016 at 12:07 PM, Wayne Warren  wrote:
>
>> On Wed, Nov 9, 2016 at 6:41 PM, Thanh Ha 
>> wrote:
>>
>> https://review.openstack.org/358019 Support explicit API and simple
>>> config creation
>>>
>>> There's also some TODO actions in the etherpad that we need to decide if
>>> we want to continue pushing for in the JJB 2.0 push.
>>>
>>
>> I think the best forum for making a decision on these items would be here
>> on the mailing list. If everyone else agrees let's start that in this
>> thread.
>>
>
> +1 that makes sense to me.
>

So on that patch:
https://review.openstack.org/358019 Support explicit API and simple config
creation

Does it make sense? I'd like to hear other people's opinion on whether it
makes sense to have an explicit API as well as a from_config(cfg) method
when someone would create the config object and then pass it around, or is
it more of a YAGNI?

Since it impacts the API that will be published, seems like it would be a
good idea to get this ironed out before releasing?

-- 
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

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

[Thanh Ha]

On Thu, Nov 10, 2016 at 12:07 PM, Wayne Warren  wrote:

> On Wed, Nov 9, 2016 at 6:41 PM, Thanh Ha 
> wrote:
>
>> There's 2 patches that need one more core-review to get merged so
>> hopefully someone can take a look at them soon:
>>
>> https://review.openstack.org/336091 Improve logger output for expanding
>> templates
>> https://review.openstack.org/206178 Add view management functionality
>>
>
> Merged, looking forward trying these out in the 2.0.0 release!
>
>
>> And these patches need some reviews:
>>
>> https://review.openstack.org/395716 Add support for view-template
>>
>
> This is a feature addition that seems to me like it could just as easily
> have landed in 1.x as in 2.0.0 or for that matter 2.1, 2.2, 2.3, etc. Are
> we blocking a 2.0.0 release on this and if so is there a technical reason
> for doing that rather than focusing on merging the changes necessary for
> 2.0.0--the goal of which remember was to refactor the API for improved
> programmatic access to JJB internals, which benefits all of us even if the
> view-template feature is not included in the first 2.x release.
>

You're right this one can be added at anytime. It would be very helpful to
us if we can get it in sooner rather than later though as we rely on views
quite a bit. At least the view patch above was merged so that will get us
by if we don't have time for this one.



>
>
>> We also have 4 patches that still need work:
>>
>> https://review.openstack.org/333076 Move macro expansion into YamlParser
>>
>
> I will find time to update this per the review comments by Friday.
>
>
>> https://review.openstack.org/309735 Output additional info when
>> exceptions occur
>> https://review.openstack.org/357960 Add convenience function for plugin
>> namespace
>>
>
I'll try to take another crack at the plugin namespace one today.



> https://review.openstack.org/358019 Support explicit API and simple
>> config creation
>>
>> There's also some TODO actions in the etherpad that we need to decide if
>> we want to continue pushing for in the JJB 2.0 push.
>>
>
> I think the best forum for making a decision on these items would be here
> on the mailing list. If everyone else agrees let's start that in this
> thread.
>

+1 that makes sense to me.


Thanh
___
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

[Wayne Warren]

On Wed, Nov 9, 2016 at 6:41 PM, Thanh Ha 
wrote:

> Hi Everyone,
>
> I'd like to keep the momentum of JJB 2.0 work going as we're so close to
> the finish line. This Friday we're going to continue our sprint in
> #openstack-sprint for those who can make it. Wayne suggested we send a
> status to the mailing list for those who can't.
>
> To summarize some of the etherpad https://etherpad.
> openstack.org/p/jjb_api_v2.0 below.
>
> There's 2 patches that need one more core-review to get merged so
> hopefully someone can take a look at them soon:
>
> https://review.openstack.org/336091 Improve logger output for expanding
> templates
> https://review.openstack.org/206178 Add view management functionality
>

Merged, looking forward trying these out in the 2.0.0 release!


>
> And these patches need some reviews:
>
> https://review.openstack.org/395716 Add support for view-template
>

This is a feature addition that seems to me like it could just as easily
have landed in 1.x as in 2.0.0 or for that matter 2.1, 2.2, 2.3, etc. Are
we blocking a 2.0.0 release on this and if so is there a technical reason
for doing that rather than focusing on merging the changes necessary for
2.0.0--the goal of which remember was to refactor the API for improved
programmatic access to JJB internals, which benefits all of us even if the
view-template feature is not included in the first 2.x release.


>
> We also have 4 patches that still need work:
>
> https://review.openstack.org/333076 Move macro expansion into YamlParser
>

I will find time to update this per the review comments by Friday.


> https://review.openstack.org/309735 Output additional info when
> exceptions occur
> https://review.openstack.org/357960 Add convenience function for plugin
> namespace
> https://review.openstack.org/358019 Support explicit API and simple
> config creation
>
> There's also some TODO actions in the etherpad that we need to decide if
> we want to continue pushing for in the JJB 2.0 push.
>

I think the best forum for making a decision on these items would be here
on the mailing list. If everyone else agrees let's start that in this
thread.


>
> Thanh
>
>
>
> ___
> 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

[Thanh Ha]

Hi Everyone,

I'd like to keep the momentum of JJB 2.0 work going as we're so close to
the finish line. This Friday we're going to continue our sprint in
#openstack-sprint for those who can make it. Wayne suggested we send a
status to the mailing list for those who can't.

To summarize some of the etherpad
https://etherpad.openstack.org/p/jjb_api_v2.0 below.

There's 2 patches that need one more core-review to get merged so hopefully
someone can take a look at them soon:

https://review.openstack.org/336091 Improve logger output for expanding
templates
https://review.openstack.org/206178 Add view management functionality

And these patches need some reviews:

https://review.openstack.org/395716 Add support for view-template

We also have 4 patches that still need work:

https://review.openstack.org/333076 Move macro expansion into YamlParser
https://review.openstack.org/309735 Output additional info when exceptions
occur
https://review.openstack.org/357960 Add convenience function for plugin
namespace
https://review.openstack.org/358019 Support explicit API and simple config
creation

There's also some TODO actions in the etherpad that we need to decide if we
want to continue pushing for in the JJB 2.0 push.

Thanh
___
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

[Darragh Bailey]

Hi,


Quick reminder that today is the fourth planned sync up for JJB v2.0 api
patches.
https://wiki.openstack.org/wiki/VirtualSprints#JJB_V2.0_API_Sprint

Time: August 19th 14:00 - 18:00 (UTC) - this friday
Venue: #openstack-meeting (IRC)


Not quite ready to land all of the remaining patches for the 2.0 API work
during the upcoming sprint slot later today, but Thanh has been kind enough
to spend some time to get some ready that can be landed.

Additionally as suggested in the IRC room yesterday, can use this timeslot
to focus on any TODO tasks and whatever else is needed to help get the
remaining patches ready for the next session!


https://etherpad.openstack.org/p/jjb_api_v2.0 has been updated with a list
of patches that can be landed.

Also included two additional patches in the etherpad that would benefit
from feedback. These are design changes to the code where there are two
reasonable directions. Thanh has helpfully moved things around so we can
delay landing these without preventing most of the remaining work from
being reviewed and approved.


Chat to you in #openstack-sprint later this afternoon.

Happy reviewing!

>
-- 
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

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

[Darragh Bailey]

Hi,


Quick reminder that we're approaching the third planned sync up for JJB v2.0
api patches.
https://wiki.openstack.org/wiki/VirtualSprints#JJB_V2.0_API_Sprint

Time: August 5th 14:00 - 18:00 (UTC) - this friday
Venue: #openstack-meeting (IRC)

Seen some great work in the first two sync-ups with 11 patches landed, 8
from the original series and 3 additional changes. Hoping for another 8+ to
land in this next session :-)

The first two sync ups help define a sensible work flow, with the second
one showing substantial productivity improvement in applying the learnings
from the initial meeting. Here's a quick reminder of those:

   - Try to review the next set of patches before the sync up start
   - Use the meeting time to agree what changes need to be made if any
   - Document changes that can be added as follow up work
   - Then look to try and sub divide some patches to spread the load


Updated https://etherpad.openstack.org/p/jjb_api_v2.0 with the next set of
patches, 8 in total, that hopefully will get landed by end of this upcoming
session. Feel free to comment on any in the entire set, this is just to
help prioritise a part of the series that needs to land before the
remainder.

As there are a few TODO's listed, I would encourage anyone interested to
help pick up the TODO's, as these are things that are needed, and can be
proposed to be landed onto the existing tree right now. These were changes
spotted where it was decided to rework it subsequently to balance the
productivity penalty of rebasing the entire series against the benefit of
making the change there. We still want these as part of the V2.0 API work,
just make more sense to do it on top.


Also included two additional patches in the etherpad that would benefit
from feedback. They are design changes to the code where there are two
reasonable directions, and will benefit from having time to step back and
have a few days to consider, rather than trying to decide right before
inclusion. So better to think about them before the sync up planned for the
19th, when they would be planned to be landed.


Chat to you in #openstack-sprint on Friday.

Happy reviewing!

-- 
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

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

[Darragh Bailey]

Hi,

Just realised I forgot to include the date/time in the email (I know it's
available via the virtual sprint wiki page, should have still mentioned it)

Next sprint/sync-up is schedule: 14:00 - 18:00 (UTC) 22nd July


On 20 July 2016 at 12:45, Darragh Bailey  wrote:

> Hi,
>
>
> Quick reminder that we're approaching the second planned sync up for JJB
> v2.0 api patches.
> https://wiki.openstack.org/wiki/VirtualSprints#JJB_V2.0_API_Sprint
>
>
> https://etherpad.openstack.org/p/jjb_api_v2.0 contains a list of 7
> patches that I'd like us to get close to merging.
>
>
> The first sync up helped clarify a few things, and I've a couple of
> suggestions to help us improve on the progress made:
>
>- Try to review the next set of patches before the sync up start
>- Use the meeting time to agree what changes need to be made if any
>- Document changes that can be added as follow up work (although
>rebasing the set with invasive reworks can help you understand how
>everything is working and help you better understand the entire series,
>it's best if we can avoid doing that for the proposed patches for the sync
>up, and do any more extensive rework outside of them).
>- Then look to try and sub divide some patches to spread the load
>
>
> I've pushed up a rebased set of Wayne's patches yesterday and this
> morning, to make it easier to follow the changes added to the series by a
> patch I've added in.
>
> Hopefully everyone gets a chance to review in time, and I think things
> will get substantially easier now after this week, hopefully see more
> landed outside of the sync-ups from next week.
>
> Chat to you in #openstack-sprint on Friday.
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool"
>



-- 
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

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

[Darragh Bailey]

Hi,


Quick reminder that we're approaching the second planned sync up for JJB
v2.0 api patches.
https://wiki.openstack.org/wiki/VirtualSprints#JJB_V2.0_API_Sprint


https://etherpad.openstack.org/p/jjb_api_v2.0 contains a list of 7 patches
that I'd like us to get close to merging.


The first sync up helped clarify a few things, and I've a couple of
suggestions to help us improve on the progress made:

   - Try to review the next set of patches before the sync up start
   - Use the meeting time to agree what changes need to be made if any
   - Document changes that can be added as follow up work (although
   rebasing the set with invasive reworks can help you understand how
   everything is working and help you better understand the entire series,
   it's best if we can avoid doing that for the proposed patches for the sync
   up, and do any more extensive rework outside of them).
   - Then look to try and sub divide some patches to spread the load


I've pushed up a rebased set of Wayne's patches yesterday and this morning,
to make it easier to follow the changes added to the series by a patch I've
added in.

Hopefully everyone gets a chance to review in time, and I think things will
get substantially easier now after this week, hopefully see more landed
outside of the sync-ups from next week.

Chat to you in #openstack-sprint on Friday.

-- 
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

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

[Darragh Bailey]

Took a bit of doing, but worked out what was needed to use #openstack-sprint

Created an entry on the Virtual Sprint wiki page:
https://wiki.openstack.org/wiki/VirtualSprints#JJB_V2.0_API_Sprint

Chat to you all tomorrow.


On 6 July 2016 at 21:01, Darragh Bailey  wrote:

> Hi,
>
> On 6 Jul 2016 20:26, "Paul Belanger"  wrote:
> >
>
> Snipped
>
> > > 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.
> > >
> > You may want to check if the #openstack-sprint channel is available on
> freenode.
> > We have logging enabled on it and seems like a natural fit for your
> agenda.
> >
>
> Fantastic, thanks for that suggestion. Even if it's not those time,
> hopefully it will be for the next ones.
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool" - unknown
>



-- 
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

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

[Paul Belanger]

On Mon, Jul 04, 2016 at 05:43:14PM +0100, Darragh Bailey wrote:
> 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.
> 
You may want to check if the #openstack-sprint channel is available on freenode.
We have logging enabled on it and seems like a natural fit for your agenda.

> 
> 
> 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

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

[Kien Ha]

I am fine with starting this Friday. I am also okay with starting any time
afterwards too.

On Wed, Jul 6, 2016 at 3:14 PM, Darragh Bailey 
wrote:

>
> Sounds like Friday is the clear winner. Do we want to stay this Friday? Or
> would everyone prefer a bit more notice to plan things with their other
> work?
>
> I'm not around Friday 15th, but it could start then anyway if others are
> happy (might need one more core to help land stuff that day)? Otherwise
> could wait until the 22nd, naturally can still do normal reviews in the
> mean time.
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool" - unknown
> On 6 Jul 2016 08:31, "Dong Ma"  wrote:
>
>> Hey Darragh,
>>
>> For Mon/Fri, the current time slots both works for me.
>>
>> Thanks,
>> Dong
>>
>>
>>
 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.
>
>
>

>>> Would moving the time slot an hour earlier on either Mon/Fri suit you
>>> better?
>>>
>>> --
>>> 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

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

[Darragh Bailey]

Sounds like Friday is the clear winner. Do we want to stay this Friday? Or
would everyone prefer a bit more notice to plan things with their other
work?

I'm not around Friday 15th, but it could start then anyway if others are
happy (might need one more core to help land stuff that day)? Otherwise
could wait until the 22nd, naturally can still do normal reviews in the
mean time.

--
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown
On 6 Jul 2016 08:31, "Dong Ma"  wrote:

> Hey Darragh,
>
> For Mon/Fri, the current time slots both works for me.
>
> Thanks,
> Dong
>
>
>
>>> 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.



>>>
>> Would moving the time slot an hour earlier on either Mon/Fri suit you
>> better?
>>
>> --
>> 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

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

[Dong Ma]

Hey Darragh,

For Mon/Fri, the current time slots both works for me.

Thanks,
Dong



>> 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.
>>>
>>>
>>>
>>
> Would moving the time slot an hour earlier on either Mon/Fri suit you
> better?
>
> --
> 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

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

[Darragh Bailey]

It's starting to sound like Friday would suit people best, I'm happy enough
with that day as well, may have to leave slightly before 17hr utc, but
should be able to be present for most of the time.

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown
On 5 Jul 2016 17:21, "Wayne Warren"  wrote:

>
>
> On Tue, Jul 5, 2016 at 6:32 AM, Darragh Bailey 
> wrote:
>
>>
>>
>> On 5 July 2016 at 05:44, Kien Ha  wrote:
>>
>>> 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.
>>>
>>
>> I can do Monday, assuming Friday is a little more awkward for people in
>> European timezones as they plan to wrap up for the day earlier.
>>
>> Woud 13:00-1700 UTC suit on those days?
>>
>>
>>>
>>> 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.



>>>
>> Would moving the time slot an hour earlier on either Mon/Fri suit you
>> better?
>>
>
> For the proposed time slots so far, Friday would be better for me--I have
> a team meeting I cannot miss between UTC 1530 and UTC 1630 (although it
> usually runs a half hour short).
>
> However, if Monday 1300 - 1700 UTC ends up being the best time for
> everyone else, I can attempt to split my attention between the JJB 2.0
> review session and that meeting, or set aside dedicated time outside of the
> review session to respond to comments and iterate on the 2.0 patches
> (really I will want to do this anyway).
>
>
>> --
>> 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

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

[Wayne Warren]

On Tue, Jul 5, 2016 at 6:32 AM, Darragh Bailey 
wrote:

>
>
> On 5 July 2016 at 05:44, Kien Ha  wrote:
>
>> 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.
>>
>
> I can do Monday, assuming Friday is a little more awkward for people in
> European timezones as they plan to wrap up for the day earlier.
>
> Woud 13:00-1700 UTC suit on those days?
>
>
>>
>> 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.
>>>
>>>
>>>
>>
> Would moving the time slot an hour earlier on either Mon/Fri suit you
> better?
>

For the proposed time slots so far, Friday would be better for me--I have a
team meeting I cannot miss between UTC 1530 and UTC 1630 (although it
usually runs a half hour short).

However, if Monday 1300 - 1700 UTC ends up being the best time for everyone
else, I can attempt to split my attention between the JJB 2.0 review
session and that meeting, or set aside dedicated time outside of the review
session to respond to comments and iterate on the 2.0 patches (really I
will want to do this anyway).


> --
> 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

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

[Darragh Bailey]

On 5 July 2016 at 05:44, Kien Ha  wrote:

> 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.
>

I can do Monday, assuming Friday is a little more awkward for people in
European timezones as they plan to wrap up for the day earlier.

Woud 13:00-1700 UTC suit on those days?


>
> 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.
>>
>>
>>
>
Would moving the time slot an hour earlier on either Mon/Fri suit you
better?

-- 
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

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