21:00:54 <EmilienM> #startmeeting crossproject
21:00:54 <openstack> Meeting started Tue Aug 25 21:00:54 2015 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:57 <openstack> The meeting name has been set to 'crossproject'
21:01:01 <EmilienM> #link Agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:01:08 <EmilienM> courtesy ping for david-lyle flaper87 dims dtroyer johnthetubaguy rakhmerov
21:01:10 <dims> o/
21:01:13 <EmilienM> courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle
21:01:15 <david-lyle> o/
21:01:16 <jokke_> o/
21:01:18 <elmiko> o/
21:01:18 <EmilienM> courtesy ping for adrian_otto mestery kiall jeblair thinrichs j^2 stevebaker
21:01:22 <hogepodge> o/
21:01:23 <EmilienM> courtesy ping for mtreinish Daisy Piet notmyname ttx isviridov gordc SlickNik
21:01:28 <EmilienM> courtesy ping for cloudnull loquacities thingee hyakuhei redrobot dirk TravT
21:01:34 <SergeyLukjanov> o/
21:01:34 <stevebaker> \o
21:01:38 <ttx> EmilienM is so good at this I propose he permanently chairs this
21:01:39 <mtreinish> o/
21:01:42 <notmyname> here (in the back of the room at a conference)
21:01:42 <EmilienM> courtesy ping for vipul lifeless annegentle SergeyLukjanov devananda boris-42 nikhil_k
21:01:43 <Rockyg> o/
21:01:45 <dhellmann> o/
21:01:48 <EmilienM> ttx: :)
21:01:53 <EmilienM> hello everyone
21:02:07 <gordc> o/
21:02:13 <ttx> short agenda, shall be quick
21:02:24 <TravT> o/
21:02:27 <ttx> annegentle: if you want to discuss meeting time move we could add it to the agenda
21:02:36 <annegentle> ttx: oh yes, please, sorry I didn't do that myself
21:02:37 <EmilienM> #topic review past actions
21:02:40 <morgan> o/
21:02:46 * edleafe is still lurking
21:02:51 <ttx> Also we'll need volunteers for next week
21:02:54 <EmilienM> ttx to followup .Z version increments on stable/liberty commits on the ML
21:03:01 <EmilienM> ttx: o/
21:03:05 <ttx> I did that in a follow-up post
21:03:08 <EmilienM> cool
21:03:11 <EmilienM> Daviey to explain why "tag now and then" is the 4th knight of the apocalypse on the ML
21:03:20 <ttx> he did that
21:03:21 <EmilienM> Daviey: o/
21:03:23 <EmilienM> cool
21:03:27 <EmilienM> and lifeless to document an in-tree solution without merge conflicts
21:03:33 <ttx> quick note on that
21:04:09 <ttx> Given how much time is left it's very likely that we'll do tag-now-and-then and in-tree release notes for stable/liberty since it doesn't require any specific development
21:04:23 <ttx> and discuss evolutions of that at the summit
21:04:33 <ttx> damn, 6 months is so short
21:04:38 <morgan> ttx: seriously
21:04:52 <dhellmann> ttx: I'm experimenting a bit with some scripts based on lifeless' approach, but it's probably wise to go ahead with a single file for now
21:04:52 <fungi> it's also a nice transition for stable branches, since we'll be starting in liberty with divergent version numbers anyway
21:05:04 <morgan> fungi: ++
21:05:10 <ttx> If we have somethgin ready by then, I'm totally open to going faster
21:05:12 <fungi> so lock-step stable point releases will be less of an expectation from the community on those anyway
21:05:19 <ttx> yeah
21:05:23 <ttx> one change at a time
21:05:38 <dims> y
21:05:42 <loquacities> i'm late to the party, but here :)
21:05:47 <ttx> for the recotd, lifeless did document his in-tree-without-merge-conflicts solution.
21:05:51 <EmilienM> cool
21:05:54 <EmilienM> #info Meeting Chairs still needed for September 1, September 29, and October 13
21:05:59 <fungi> and also, yes, 6 months is far too short
21:06:33 <EmilienM> gordc: if you accept to be chair next week, I'll come in Toronto and give you cookies
21:06:36 <ttx> I won't take Sept 1 because that's liberty-3 week and I'll be very busy gettign Launchpad aligned with reality together with PTLs
21:06:53 <ttx> I advise dhellmann not to volunteer either
21:06:58 <gordc> EmilienM: what sort of cookies? chocolate chip?
21:07:05 <ttx> but anyone else is welcome to
21:07:06 <EmilienM> whatever you like
21:07:12 <dims> EmilienM: i can volunteer
21:07:16 <dhellmann> ttx: ack
21:07:26 <EmilienM> dims: feel free to update https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
21:07:26 <dims> for Sept 1
21:07:33 <EmilienM> thx guys!
21:07:40 <ttx> dims: Sold! add you to the page
21:07:47 <EmilienM> #topic Team announcements (horizontal, vertical, diagonal)
21:08:00 <ttx> release management:
21:08:01 <ttx> As a reminder, we have liberty-3 next week, and a number of project will tag a b3 there
21:08:10 <jokke_> I can take the 29th if no-one else is bidding for it :P
21:08:17 <ttx> For those, please join us on #openstack-relmgr-office during Tuesday (September 1st) so that we can help you clean up your Launchpad pages to match what was done since b2
21:08:25 <ttx> jokke_: sold too!
21:08:34 <ttx> jokke_: add yourself to the wikipage
21:08:38 <lifeless> ok, electrician gone
21:08:41 <lifeless> I'm actually here now
21:08:54 * dims pays more attention if he is running the meeting :)
21:09:03 <ttx> lifeless: i defneded your honor and confirmed you completed your assigned action
21:09:10 <annegentle> API docs
21:09:43 <annegentle> Sent a status update to the ML
21:09:45 <annegentle> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072557.html
21:10:03 <EmilienM> ttx: should I remind PTLs to reply to your email about summit rooms?
21:10:15 <annegentle> and then also asked if any project other than nova generates their request and response samples
21:10:17 <annegentle> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072743.html
21:10:41 <elmiko> i responded to that too annegentle
21:10:42 <ttx> EmilienM: can't hurt. If they don't, defaults to one workroom and a half-day meetup on Friday afternoon.
21:11:32 <Daviey> (sorry, in a real life meeting)
21:11:48 <EmilienM> do we have any other announcements?
21:12:26 <EmilienM> I guess no
21:12:44 <EmilienM> #topic Open discussion
21:13:00 <morgan> I like short meetings
21:13:03 <EmilienM> anything you want to discuss that was not in agenda, please go ahead
21:13:16 <rbradfor> I added an item to the agenda. sorry was few mins late
21:13:17 <EmilienM> oh we actually have two things
21:13:22 <EmilienM> I should have refreshed my Firefox
21:13:34 <EmilienM> #topic Having a centralized and web visible place for code coverage of projects
21:13:50 <EmilienM> rbak: go ahead
21:13:52 <EmilienM> oops
21:13:54 <rbradfor> has anybody proposed to have say a cover.o.o centralized home for coverage tests of projects
21:14:14 <rbradfor> There are several justifications to consider.
21:14:16 <EmilienM> not afik
21:14:20 <morgan> that would be relatively interesting to have
21:14:31 <Rockyg> haven't seen a proposal lately, but I'm +100
21:14:32 <rbradfor> 1. It helps new contributors to look for low hanging fruit to consider unit tests of code.
21:14:32 <clarkb> rbradfor: maybe we can describe what the problems are with the existing implementation (there are many I am sure)
21:14:33 <annegentle> EmilienM: oh I did add to the agenda
21:14:35 <clarkb> and go from there?
21:14:44 <EmilienM> annegentle: don't worry, it will be next topic
21:14:50 <annegentle> EmilienM: ok thanks
21:15:16 <fungi> i think this may dovetail into earlier discussions for a job dashboard (which could provide access to results of post-merge, tag-related and periodic job runs)
21:15:23 <rbradfor> 2. We can see overall coverage % across projects, and ideally we want to track % (specifically a decreasing % over time for new code)
21:15:44 <clarkb> 2. is possible today, its just not cleraly exposed
21:15:51 <rbradfor> a few projects have non-voting gates that publish code coverage, but it's just logs.
21:16:00 <morgan> rbradfor: so this has come up before, you can easily get a reduction in % of coverage without a negative impact to the code.
21:16:01 <fungi> rbradfor: not at all
21:16:31 <fungi> we upload the html coverage reports along with them
21:16:38 <rbradfor> morgan, agreed, but overtime would it not be a good practice to see code coverage increase
21:16:42 <jokke_> I'd really love to see initiative to improve the quality of the tests rather than quantity :P
21:16:46 <clarkb> fungi: yup, so maybe whatwe need is just an index into the latest coverage report html
21:16:51 <morgan> rbradfor: sure.
21:17:02 <clarkb> fungi: and possibly generate that index with some scraped summary data
21:17:07 <mtreinish> rbradfor: also some projects have post queue jobs that generate those reports, but they're kinda hard to discover
21:17:08 <fungi> clarkb: yeah, i think that was one of the features desired for a job dashboard
21:17:08 <morgan> jokke_: subjective vs objective. thats a hard comparison
21:17:10 <rbradfor> clarkb, a central place for an index, even a wiki page is a start
21:17:20 <morgan> jokke_: not that i disagree
21:17:57 <morgan> rbradfor: just wanted to highlight a concern last time this came up (with blocking patches that reduced % of coverage)
21:18:02 <fungi> #link http://logs.openstack.org/82/165682/8/check/nodepool-coverage/08c6340/cover/
21:18:03 <fungi> an example
21:18:09 <rbradfor> here is an example of published reports from a jenkins job http://logs.openstack.org/38/212738/12/check/designate-coverage/bc2e329/
21:18:15 <jokke_> morgan: it is, but rubbish unit tests to increase the coverage benefits no-one but the one who looks the coverage figures ;)
21:18:26 * jokke_ is not huge fan of unit tests
21:18:28 <morgan> rbradfor: as long as we're careful with what we use this for.
21:18:30 <rbradfor> the HTML is available for viewing.
21:18:58 <morgan> jokke_: the move to functional tests is good as well fwiw, but that requires a different metric. unit tests have their place
21:18:58 <rbradfor> morgan, I agree, blocking patches with reduce coverage is not a solution.
21:18:59 <EmilienM> it's the same
21:19:47 <fungi> in fact, any time we set an arbitrary limit for rejecting changes, we find that most projects very quickly approach that limit. and if we move the milit, they very quickly reconverge at the new one
21:20:18 <fungi> maximum job run time and maximum test run time are good examples, as are memory utilization and disk utilization
21:20:25 <rbradfor> my initial objective is to expose worthwhile information.
21:20:30 <EmilienM> jokke_: being fan is not an option but is required to write good code I guess
21:20:59 <Rockyg> I think just having the coverage for all projects that do it locatable, no gates/triggers/etc, would provide food for test minded developers
21:21:04 <rbradfor> the code coverage you can run on your own projects, but it's not published (consistently)
21:21:23 <ttx> rbradfor: sounds like something you could raise on a ML thread to flesh out the goals, start the design and find volunteers
21:21:30 <fungi> well, it's published consistently, it's just not easy to find
21:21:36 <EmilienM> ttx++
21:21:37 <rbradfor> ttx, good point. I'll start there.
21:21:45 <clarkb> fungi: right I think all it needs as a starting point is an index
21:21:55 <ttx> but I agree with fungi that it would be good to not limit to code coverage
21:22:00 <rbradfor> fungi, can you explain what you mean by "not easy to find"
21:22:01 <EmilienM> sounds like we need to solve the "easy to find" potential issue
21:22:05 <fungi> also i think at the last summit there was pretty broad support for a test results dashboard for this sort of thing
21:22:07 <jokke_> EmilienM: I've seen lots of good code without single unit test, I've seen lots of rubbish code with even worse unit tests. Proves otherwise I think :P
21:22:11 <morgan> fungi: ++
21:22:28 <fungi> rbradfor: there's no simple index to them. you need to generate log urls based on commit ids
21:22:29 <morgan> fungi: I think that is going to be more and more relevant as we move towards funcitonal testing for projects
21:22:35 <ttx> it's been on a the wanted list forever, just not enough people (or days in the week)
21:23:01 <Rockyg> so, plan to get a spec started is to go out to infra and get what they know about coverage, location of outputs, etc.  Then write a strawman and start the discussion on the ML
21:23:05 <rbradfor> my first objective is to expose the information to identify areas people *can* write unit tests for
21:23:30 <Rockyg> rbradfor, or functional tests...
21:23:41 <fungi> #link https://review.openstack.org/192253
21:23:54 <rbradfor> Rockyg, yes functional also
21:24:08 <fungi> that i think is the current tangible output from the summit discussions
21:24:24 <fungi> so might be a good idea to pick that up and run with it
21:24:27 <rbradfor> fungi, thanks for the spec
21:24:53 <Rockyg> or run with a section of it...subspec kinda
21:25:11 <clarkb> and yes the coverage html report things that are shiny for humans to look at are published to deterministic locations. The current miss there is we don't index them so that deterministic location isn't clear to everyone
21:25:14 <fungi> yeah, at any rate discuss the coverage publishing interest in terms of that proposed spec
21:25:28 <clarkb> so a dashboard can simply find the HEAD commit and link to the report
21:26:36 <fungi> and trending wouldn't be too hard, though would probably involve parsing some output (and would have similar test name mutability issues that refstack is dealing with)
21:27:29 <rbradfor> if we keep the text version of the coverage report, even say weekly, it is very easy to publish trending data.
21:27:37 <fungi> i suppose that depends on the granularity/specificity of what you hope to trend though
21:28:18 <fungi> trending overall coverage on a per-repo basis wouldn't be too hard. trending per-file runs into issues with files getting renamed, split, combined, et ecetera
21:28:37 <morgan> fungi: i'd go for overall coverage to start
21:28:46 <morgan> per file is something people can drill down into if they *really* care
21:29:07 <morgan> eventually we might go that way at the index level
21:29:13 <morgan> but probably not worth it from an initial pass
21:29:24 <Rockyg> Yeah.  Getting *something* to start with lets us explore how to get more.
21:29:50 <fungi> oh, also one other challenge is retention. currently we only retain a few months of these reports, so long-term trending would need a separate mechanism
21:29:50 <rbradfor> I'll take this input and structure a ML email for wider discussion. Thanks for the feedback.
21:30:10 <mtreinish> fungi: also normally you don't care about the coverage of the test itself it's more the other code
21:30:18 <mtreinish> that's being tested
21:30:20 <EmilienM> rbradfor: thx
21:30:24 <mtreinish> so I'm not sure the name thing applies
21:30:25 <morgan> fungi: I smell a use for graphite or a similar thing. ;)
21:30:28 <Rockyg> mtreinish, ++
21:30:37 <rbradfor> fungi, technically you can always regenerate the code coverage for a commit.
21:30:38 <Rockyg> morgan, ++
21:30:41 <clarkb> mtreinish: Rockyg the name thing applies to files changing names or functions moving
21:30:56 <morgan> mtreinish: I run coverage reports on my coverage reports /s
21:31:04 <EmilienM> can we go ahead in the agenda?
21:31:10 <lifeless> rbradfor: well, you can regenerate /a/ code coverage
21:31:10 <mtreinish> clarkb: sure, but that's not easily solved like we did it in tempest
21:31:34 <lifeless> rbradfor: but there's sufficient nondeterminism that I'd not be willing to sign up for /the/ :)
21:31:39 <Rockyg> clarkb, Yeah.  I'm deep in refstack.  But the coverage doesn't have to report which *test* covered the code.  Just that specific code was covered.
21:31:41 <mtreinish> morgan: heh, you joke but at one time there was a coverage tempest run which showed how much of tempest was executed :)
21:31:55 <mtreinish> I never did understand what that was for
21:32:11 <morgan> i.. ok annnyway
21:32:13 <lifeless> mtreinish: didn't it measure the apis under test?
21:32:30 <lifeless> I swear we did have something
21:32:34 <mtreinish> lifeless: no, that was a different thing
21:32:39 <lifeless> I meant to dive on it and make it better but ETIME
21:32:45 <mtreinish> lifeless: that was: https://wiki.openstack.org/wiki/Nova/CoverageExtension
21:33:15 <mtreinish> we pulled that out because coverage under eventlet was wonky. It's fixed in the 4.0 release
21:33:50 <fungi> rbradfor: well, i'd be surprised if you could conveniently rerun a coverage report (or even successfully run the unit tests you'd need) for a commit from 2 years ago
21:34:05 <lifeless> fungi: constraints will make that reasonably straight forward
21:34:15 <fungi> we have enough trouble just keeping year-old branches running tests reliably
21:34:17 <lifeless> fungi: but still some non-determinism
21:34:24 <fungi> lifeless: true
21:36:04 <rbradfor> well, I'm happy to work forward for now, getting historical coverage data is a wishlist.
21:36:20 <Rockyg> rbradfor, ++
21:36:22 <EmilienM> good
21:36:29 <EmilienM> I suggest to continue on ML that too
21:36:52 <EmilienM> rbradfor, lifeless, fungi, mtreinish: sounds good?
21:37:06 <EmilienM> let's continue the meeting
21:37:09 <EmilienM> #topic Proposed change to time of cross-project meeting
21:37:11 <EmilienM> annegentle: o/
21:37:18 <EmilienM> #link https://review.openstack.org/#/c/214605/
21:38:11 <annegentle> hey
21:38:26 <annegentle> so ttx just suggested the odd/even trade off which might serve this meeting well
21:38:29 <annegentle> what do you all think?
21:38:51 <morgan> i was going to say even/odd trade would be better, because at 1300 UTC, I wont ever be there (as an example)
21:39:16 <annegentle> I can propose 1300 and what additional time then works well? 0100?
21:39:20 <clarkb> 1300utc is something like 6am PDT and earlier when on PST
21:39:37 <morgan> I would keep this time as the alternate.
21:39:42 <morgan> personally.
21:39:45 <ttx> +1
21:40:46 <annegentle> morgan: ah, ok
21:40:50 <fungi> i wonder whether alternating meeting times will eventually result in two different groups of people meeting once every two weeks, but i'm not opposed since i can attend whatever time it's scheduled and have no idea how many others are similarly flexible/crazy
21:40:55 <morgan> 1300 UTC alternating I would definitely make an effort and probablly make it to ~3/4+ of the meetings but always at 1300 I'd make less than half.
21:41:16 <annegentle> so, 1300 and 2100 alternating
21:41:23 <jokke_> I personally love the time, but yeah sounds bit harsh for the far West (and that's lots from me as I normally don't care some odd harsh most of these being bit nasty for us here in Europe and equally ridiculous for people East from us)
21:41:23 <annegentle> I can definitely propose it
21:41:37 <morgan> An alternative that wouldn't be *awful* is likely 1700UTC [not sure who that conflicts with]
21:41:55 <ttx> annegentle: you should update the thread as well, not everybody follows irc-meetings changes
21:41:56 <Rockyg> the 0100 is better for APAC
21:41:56 <morgan> or even 1600
21:42:08 <morgan> but that is all personal bias.
21:42:46 <jokke_> 1600/1700 UTC is pretty much never gonna make it
21:43:25 <jokke_> Either those slots are already booked for all kind of cross continent meetings, or then I'm trying to migrate from office to home
21:43:26 <annegentle> morgan: started with 1700, Euro eats then apparently
21:43:33 <EmilienM> I think we can debate a lot of time, we will never make everyone happy - meeting slots are always the same discussion
21:43:34 <morgan> annegentle: ah.
21:43:44 <morgan> anyway i'd be fine with 1300/2100
21:43:58 <annegentle> right, so really just wanted to start the convo, see if alternating is needed, see if this meeting could be more finely tuned
21:44:04 <fungi> part of me wonders whether the americas-centric meeting times are the reason why we have so many fewer emea/apac contributors and makes me want to avoid the appearance that we're picking meeting times out of sheer convenience for the current contributors. then there's another part of me which wonders if we'll simply be alienating the majority of our contributors by picking non-americas-convenient
21:44:06 <fungi> times, and will manage to achieve cultural balance through sheer attrition
21:44:23 <jokke_> I think the 1300 would give us few odd APJ folks coming in as well
21:44:27 <morgan> fungi: i think a little of column a and a little of column b
21:44:39 <annegentle> fungi: it really started with me and sdague lamenting our ability to get to this meeting time :)
21:45:14 <annegentle> fungi: 'course it all gets adjusted again for that silly hour time change and all, but it feels like we've had this slot "forever" so also testing if we should try to get more people to this meeting
21:45:42 <jokke_> fungi: can we still say that majority of contributors are AMS ?
21:46:03 <ttx> fungi: yeah, alternating meeting times is a bit of a two-edged sword
21:46:21 <fungi> jokke_: last numbers i saw were, but i don't have extremely recent data now
21:46:25 <ttx> I fear it will result in further marginalizing this meeting
21:46:42 <gordc> ttx: is the idea to have ML first and irc meeting second still the proposed rule?
21:46:56 <EmilienM> if the meeting concerns PTL & TC? Let's make a vote using doodle or something
21:47:27 <Rockyg> Well, maybe office hours to get xproject champions for those who are on the wrong side of the globe at least?  Something to give them more voice?
21:47:29 <ttx> PTLs are the primary attendance
21:47:30 <fungi> we've had ml discussions in the past where it was suggested that the fairest way to schedule is to pick the meeting time which is the least convenient for all participants, but that strikes me as an absurdly solomonesque position
21:47:47 <jokke_> rotating meeting time ... each week an hour later :P
21:48:20 <annegentle> ttx: I worry about this meeting too
21:48:26 <annegentle> jokke_: chase the clock, go!
21:48:41 <annegentle> Rockyg: heh on "wrong" side :)
21:48:47 <morgan> annegentle: This is sounding like something we can get more feedback on at the summit as well.
21:48:55 <morgan> we have access to more people there than here.
21:48:57 <annegentle> morgan: ayup
21:49:27 <morgan> annegentle: lets definitely plan for some "chase folks down and ask 'sooo that cross project meeting...'' :)
21:49:29 <annegentle> morgan: it's odd that more people would be in person than in front of computers, tho
21:49:34 <annegentle> morgan: good idea
21:49:35 <ttx> We might want to think a bit more about the topic of this meetign before we change the time
21:49:44 <morgan> the ML has good reach, but it's a firehose
21:49:44 <Rockyg> Start a mailing list discussion, then wrap up at summit?
21:49:56 <morgan> IRC is a bit limited in who happens to be looking
21:49:59 <fungi> certainly, to some extent asking in the current meeting how many more people would attend a meeting time will result in some significant selection bias
21:50:01 <annegentle> ttx: yes, does this meeting serve the purpose of cross-project work discussion
21:50:07 <ttx> At this point it seems to be a reserved slot in the week where people can push cross-project things they want to discuss with peers
21:50:15 <morgan> this is a combined effort, talking here. ML to seed ideas, what is the topic, and in-person summit questions on timing
21:50:28 <EmilienM> morgan: with [tags] it's not too bad except if you follow a lot of projects - I agree with you though
21:50:32 <jokke_> ttx: mind to open up a bit?
21:50:43 <morgan> EmilienM: it's better with [tag], it is still a firehose
21:50:44 <ttx> If that is the case, then having multiple reserved slots in the week for people to choose from might be a solution
21:50:59 <clarkb> EmilienM: heh not too bad? I have >10k unread emails :(
21:51:04 <morgan> ttx: more office hours for x-project than a dedicated meeting?
21:51:11 <morgan> or am i mis-reading the suggestion
21:51:29 <EmilienM> clarkb: I personally follow [all] [infra] [puppet] and I don't spend more than one hour per day in e-mails
21:51:58 <jokke_> ttx: problem with that is that then you have multiple small groups who never talks to each other as no-one ever reads the logs and everyone picks the time most suitable :D
21:52:10 <ttx> jokke_: yes
21:52:12 <EmilienM> we have 9 min left guys
21:52:19 <EmilienM> we might want to keep 5 min for open discussion
21:52:37 <ttx> it's a difficult topic. I'd like to discuss that in Tokyo too, if only as a group therapy
21:53:06 <ttx> it just feels wrong to define times when we are still struggling defining what this meeting is about :)
21:53:09 <jokke_> ttx: yeah, then we can suffer next cycle of half sleep meetings
21:53:15 <Rockyg> Yeah.  Office hours would help for some of the stuff.
21:53:16 <EmilienM> ttx: can we take an action to follow up that discussion,
21:53:48 <annegentle> group therapy please
21:53:50 <EmilienM> ttx: like, organize a summit session about crossproject discussion & meetings
21:54:20 <ttx> EmilienM: sure, you can action me on that. I hoped we would have a better idea before
21:54:32 <jokke_> coffee break by the restroom doors :)
21:54:33 <ttx> it's a bit of a punt
21:54:50 <EmilienM> #action ttx to create a summit session about crossproject discussion & meetings
21:55:00 <ttx> it's like "this is a mess, we don't klnow how to fix it, but we'll talk 40 min about it in Tokyo and not make that much progress there
21:55:11 <annegentle> hence the group therapy request :)
21:55:17 <jokke_> ++
21:55:28 <EmilienM> it seems we have two issues here: the time slot and the purpose of this meeting - am I wrong?
21:55:36 <annegentle> "cross project work is difficult and slow, how can we make it better"
21:55:48 <ttx> I'd say the purpose of this meeting and maybe the time slot
21:55:51 <jokke_> Lets hug and make almos everyone uncomfortable :D
21:56:03 <ttx> depending on the purpose the current timeslot may make sense
21:56:10 <annegentle> right
21:56:15 <EmilienM> we can fix them independently
21:56:20 <ttx> like if the goal is to exclude China, it works pretty well.
21:56:22 <annegentle> or "time slot change ain't gonna fix"
21:56:25 <annegentle> ttx: ha
21:56:26 <EmilienM> or maybe not
21:56:48 <ttx> but yeah, I'll come to that session armed with data from this cycle
21:56:49 <jokke_> open discussion
21:56:50 <EmilienM> today, they target PTLs & TC so why not doing a vote by using doodle or something?
21:56:54 <jokke_> (might lead back)
21:57:09 <EmilienM> ok let's open it
21:57:13 <EmilienM> #topic open discussion
21:57:18 <ttx> what was discussed, what could have been discussed somewhere else, what should probably have been discussed and wasn't
21:57:25 <EmilienM> let's talk about cross project meeting time slots !
21:57:27 <EmilienM> :)
21:57:42 <Rockyg> :P
21:57:54 <EmilienM> 3 minutes left, please raise any topic not in our agenda
21:58:01 <jokke_> so can we define the purpose for this meeting by the slot where it will land?
21:58:05 <ttx> I think part of the issue is that we lack good digest information on the upstream side
21:58:24 <clarkb> fyi multinode testing is a thing we can and do do it. Just throwing that out there as I know there has been some confusion about it and many still think we cannot do it
21:58:25 <ttx> we have plenty of blogs and newsletter to cover chanegs in the downstream ecosystem
21:58:45 <ttx> not so much to help us deal with everything that happens on the open source project side
21:59:01 <EmilienM> clarkb: any doc? useful link?
21:59:04 <ttx> we can't really rely on the weekly newsletter to keep in touch
21:59:12 <fungi> clarkb: that reminds me. the dvr multinode testing spec is hanging out there awaiting review. we should do something with it (bless it, reject it, provide new feedback). i'm rereading it now
21:59:28 <EmilienM> openstackreactions is a good start though
21:59:30 <ttx> so I suspect part of the solution will be to reformat our development news
21:59:37 <clarkb> EmilienM: nodepool documents it let me get a link
21:59:47 <clarkb> fungi: it should be abandoned
22:00:04 <clarkb> fungi: the design in there never took into account that we were running on clouds that don't give us shared l2
22:00:13 <EmilienM> I need to close the meeting now
22:00:19 <EmilienM> thanks everyone
22:00:20 <fungi> clarkb: thanks
22:00:24 <fungi> thanks EmilienM!
22:00:26 <ttx> Thanks EmilienM !
22:00:28 <jokke_> thanks
22:00:33 <EmilienM> #endmeeting