21:01:27 <ttx> #startmeeting project
21:01:28 <openstack> Meeting started Tue Aug 19 21:01:27 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:29 <mikal> Hi
21:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:32 <openstack> The meeting name has been set to 'project'
21:01:42 <ttx> Our agenda for today is available at:
21:01:46 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:01:52 <ttx> #topic News from the 1:1 sync points
21:01:58 <ttx> Here is the log link:
21:02:05 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-08-19-08.01.html
21:02:15 <ttx> Trove and Heat were skipped due to midcycle meetups. We missed Glance as well, ptl in vacation
21:02:31 <ttx> dolphm wanted to raise attention to https://review.openstack.org/#/c/113294/ which blocks their high-prio keystone-to-keystone-federation blueprint
21:02:48 <ttx> so requirements-core can help there ^
21:02:58 <stevebaker> here for Heat
21:03:00 <dolphm> it's worth noting that it requires a binary dependency
21:03:02 <zaneb> ttx: I'm sending stevebaker on over for Heat questions
21:03:15 <dolphm> (xmlsec1)
21:03:17 <ttx> zaneb: ok, thx!
21:04:00 <ttx> dolphm: is that the only choice for SAML in Python?
21:04:20 <dhellmann> dolphm: is that in the image infra has for the testing systems?
21:04:39 <mtreinish> ttx: https://wiki.python.org/moin/SAML
21:04:42 <dolphm> ttx: i can't answer that myself - marekd stevemar ^
21:04:43 <dhellmann> I assume so, if the requirements installation job passed
21:05:05 <dolphm> dhellmann: not sure of that either - how do i check?
21:05:15 <dolphm> dhellmann: assuming you're referring to xmlsec1
21:05:39 <dhellmann> dolphm: yeah, I'd have to ask someone in -infra, but I think if the tests for that requirements change passed you're ok
21:05:46 <clarkb> if this is needed by unittests we need to add it explicitly
21:05:46 <dhellmann> I do see a couple of other saml packages on pypi
21:05:53 <dhellmann> https://pypi.python.org/pypi?%3Aaction=search&term=saml&submit=search
21:05:55 <clarkb> if it is only on the devstack side of things then devstack takes care of it
21:06:06 <clarkb> and our image machinery will cache packages that devstack says it needs
21:06:26 <ttx> The lasso lib is packaged in Ubuntu at least
21:06:28 <dhellmann> clarkb: are the images for the unit tests the same as the image for the requirements check jobs?
21:06:44 <clarkb> dhellmann: no, requirements check jobs are devstack based
21:06:46 <dolphm> dhellmann: cool. the catch might be that we need to issue saml docs, not just read/verify them
21:06:51 <stevemar> dolphm, ttx i think so, the others are fairly out of date, or not as functional
21:06:52 <jeblair> are we setting ourselves up for more pain similar to lxml?
21:06:54 <clarkb> dhellmann: so very minimal, then devstack installs the deps
21:07:23 <marekd> stevemar: dolphm ttx: agreed with stevemar.
21:07:24 <dhellmann> clarkb: hmm, ok. I knew it was devstack-gate, but I didn't realize it ran devstack itself.
21:07:46 <ttx> jeblair: could you elaborate on lxml pain?
21:08:13 <ttx> I remember pain due to code copies, but i suspect it's not the pain you're referring to
21:08:45 <clarkb> the problem with lxml is that if I pip install `python-keystoneclient` as a dependency of something else without some dev packages in place lxml won't build
21:08:56 <clarkb> now keystoneclient doesn't work because the rest of its dependencies were never installed
21:09:18 <ttx> clarkb: ok
21:09:20 <dolphm> clarkb: keystoneclient shouldn't *require* lxml, nor should keystone
21:09:22 <clarkb> it breaks the simple use case of use cloud
21:09:32 <dhellmann> is this for keystone, or keystone client?
21:09:47 <dolphm> clarkb: but of course it's in the requirements.txt .... i'll follow up on that :)
21:09:54 <clarkb> dhellmann: client
21:10:10 <dhellmann> ok, then do we know if that binary dependency is available for windows and mac platforms?
21:10:12 <jeblair> dolphm: i think mordred proposed a change to try to remove it, and then found out why it was required?
21:10:17 <dolphm> dhellmann: this will be for keystone first. keystoneclient later, marekd?
21:10:20 * jeblair digs
21:10:36 <clarkb> jeblair: yup, the xml.etree and lxml.etree objects are different
21:10:39 <jeblair> https://review.openstack.org/#/c/114701/
21:10:41 <dhellmann> dolphm: if it's in the client, what impact will that have one cloud users not running on linux?
21:11:00 <dolphm> jeblair: it should only be required for a plugin, but i could be wrong
21:11:01 <clarkb> there is a tag search or some such in lxml.etree that xml.etree dones't have and keystoneclient uses. So keystoneclient could write a manual search using xml.etree
21:11:03 <ttx> We don't have to solve this one now, but since it blocks a major Juno keystone feature, it would be great to have closure on that issue sooner rather than later
21:11:04 <marekd> dolphm: i don't think keystoneclient will need it at all. It will send openstack token, get assertion, and pass it to a remote keystone.
21:11:07 <dolphm> same for xmlsec1
21:11:10 <ttx> so maybe we can move to a thread
21:11:15 <alexpilotti> dhellmann: lxml is available for Windows
21:11:23 <dolphm> ttx: ++
21:11:29 <jeblair> dolphm: yeah, it is, but i think it's a tested one, so we still need it
21:11:29 <dhellmann> alexpilotti: what about the new dependency for this saml lib?
21:11:36 <ttx> now that people are all excited about it
21:12:11 <ttx> #info Adding pysaml2 dependency to global requirements is not a slam dunk -- watch out for upcoming ML thread
21:12:19 <jeblair> dolphm: oh, he moved it to test-requirements, so actually i don't know what was wrong with his change: https://review.openstack.org/#/c/114701/2/test-requirements.txt
21:12:23 <dolphm> lol
21:12:27 <ttx> #action dolphm to push pysaml2 requirements addition to -dev ML
21:13:03 <jeblair> but yeah, if we are able to solve the lxml issue, that will be really nice for users, and i wouldn't want to backslide on it
21:13:08 <ttx> #topic Other program news
21:13:12 <ttx> Any other program with a quick announcement ?
21:13:21 <mtreinish> nothing from me
21:13:30 <clarkb> just a reminder that infra is updating tox and defaulting test nodes to trusty tomorrow
21:13:31 <mtreinish> oh, except for the devstack governance change being merged
21:13:44 <clarkb> this is ahead of feature freeze so should be fine and I have done quite a bit of testing
21:13:48 <clarkb> do ping if you notice oddities
21:14:00 <stevebaker> I don't think heat is even close to working with new tox
21:14:12 <gordc> i think we're good in ceilometer. if we can get QA help on grenade testing that'd be cool :) https://review.openstack.org/#/c/102354
21:14:17 <ttx> We have FPF coming up Thursday for most projects, so I expect a surge in last-minute change uploads
21:14:22 <jeblair> stevebaker: it's a one line change to fix it
21:14:30 <ttx> followed by one week of high gate activity
21:14:38 <ttx> followed by one week of pure craziness
21:14:55 <ttx> followed by one week of feature freeze exceptions
21:15:09 <stevebaker> jeblair: I tried zeroing the seed but there were still test failures, haven't had a chance to look into it yet
21:16:10 <ttx> OK, anything else before we move to next topic?
21:16:45 <ttx> #topic Design summit format evolution (can we make that time as efficient as midcycle meetups ?)
21:16:56 <ttx> So... Somewhere lost in the Nova core requirements thread we have an interesting discussion
21:17:08 <ttx> Noting that mid-cycle meetups are quite successful at aligning key contributors culture, reaching consensus and generally getting things done
21:17:22 <ttx> What makes them so needed is partly because we fail to reach such alignment at the Design Summits, which are in theory designed for that
21:17:33 <ttx> So I would like to use the remaining time in this meeting to brainstorm
21:17:45 <ttx> Brainstorm things we could still change for the Kilo Design Summit in Paris to make it our most worthwhile F2F time of the cycle again
21:18:08 <ttx> We can't really fix the fact that it happens the same week as the conference
21:18:15 <mikal> So, first difference I notice
21:18:21 <clarkb> stevebaker: I tested it and it works with zeroed seed
21:18:25 <mikal> With the mid-cycle, we had a list of topics and then found speakers
21:18:33 <stevebaker> clarkb: ok, I'll give it another crack
21:18:37 <mikal> With the summit, we take things from a list of proposed sessions
21:18:41 <ttx> but we can fix the format of the sessions, or dedicate some open time to core discussions
21:18:48 <jogo> mikal: ++
21:18:55 <mikal> Well, I'm going to try brainstormging the topic list as a group this time
21:19:02 <mikal> And then finding speakers for each "winning" topic
21:19:13 <jogo> one thing the midcycles are really poor at is cross all project issues
21:19:20 <dhellmann> someone on the list mentioned no "info dump" sessions, which I think is mostly a good idea, with possible exceptions
21:19:26 <ttx> From my perspective, each program gets time slots and should do what' sthe best use they have for it
21:19:26 <dhellmann> mikal: I like that approach
21:19:32 <jeblair> ttx: ++
21:19:33 <stevebaker> If you're not a project which has sessions for the entire summit then the pods can resemble what happens at a mid-cycle meetup
21:19:34 <jogo> I think it would be nice to focus more attention on the cross project things
21:19:35 <reed> jogo: +1
21:19:40 <dhellmann> jogo: excellent point, maybe more cross-project sessions
21:19:48 <gordc> mikal: how do you decide the 'winners'?
21:19:50 <reed> and interaction with users
21:19:52 <dhellmann> stevebaker: +1
21:19:53 <ttx> If the 40-min slots prevent anything...
21:19:54 <jeblair> apparently the idea of combining slots to make bigger sessions was not widely known as something that could be done
21:19:56 <dolphm> mikal: we've started to turn that around in keystone already. going into the atlanta summit, we already had a list of "bucket" topics for things we knew we wanted to cover, and then all accepted topics ended up in one of those pre-defined buckets
21:20:04 <dhellmann> stevebaker: unless your team ends up having to participate in other project sessions :-)
21:20:08 <mikal> gordc: we have a -drivers group who would probably do that... the people who approve specs
21:20:09 <reed> and interaction with other 'influencers'
21:20:21 <mikal> #link https://etherpad.openstack.org/p/kilo-nova-summit-topics is my attempt to start brainstorming
21:20:28 <mikal> Although its not announced / advertised yet
21:20:34 <ttx> mikal: so you would simply not use the "session proposal site" ?
21:20:35 <mikal> Given I only started late last night
21:20:40 <ttx> and just make up a scehdule ?
21:20:50 <mikal> ttx: I think we'd have to use the site to get the schedule app working
21:20:57 <mikal> ttx: but we might pre-seed it with things we want to see
21:21:01 <gordc> mikal: cool cool. yeah that matches up with how we plan our meetup
21:21:12 <ttx> mikal: right, but we would not use it as a way to build the agenda
21:21:16 <dhellmann> I might use a hybrid approach, and allow some proposals from outside of the oslo drivers but reserve a number of slots for our ringer sessions
21:21:26 <mikal> dhellmann: Yeah, I imagine we'll do the same
21:21:38 <rockyg> bucket topics are key.  How about allot time for bucket, then separate time for serendipidity topics?
21:21:39 <mikal> A bucket list of core topics, and then take the rest from proposals
21:22:10 <rockyg> mikal: ++
21:22:12 <dolphm> mikal: ++
21:22:28 <mikal> Nova also gets fewer sessions each summit
21:22:35 <mikal> So we need to learn to be more efficient with our time
21:22:50 <rockyg> Also, a final wrap up session that solidifies focus for the coming release?
21:22:52 <ttx> mikal: would you be using 40-min slots for your topic list ? Or more a generic 2-hour prebooked area in the schedule ?
21:22:54 <dolphm> with 8 or 9 slots, keystone only ended up with 1 non-bucketish slot
21:23:06 <mikal> ttx: I am unsure. I don't have an opinion yet.
21:23:17 <ttx> called something intimidating like "core contributors gathering"
21:23:22 <mikal> ttx: it would also be good to not have full day nova things this time around
21:23:31 <ttx> FWIW Neutron had generic "culture" slots last time
21:23:31 <jgriffith> my head exploded :)
21:23:31 <mikal> I'd prefer half days to let people hallway track contentious things
21:23:35 <notmyname> nova shouldn't really complain about the number of slots they get at the summit ;-)
21:23:49 <dolphm> mikal: +++
21:23:57 <ttx> notmyname: sssh, if they drop some that frees more for the others!
21:24:06 <jgriffith> one of the things I've noticed seems to "help" with the meetups is no time assignments
21:24:09 <mikal> notmyname: not complaining, noting we need to learn to fit into a smaller thing
21:24:13 <jgriffith> maybe a blend of that and time limits?
21:24:31 <mikal> jgriffith: yeah, some things need to be time boxed or they never end
21:24:32 <jgriffith> jogo: problem is as you said cross-project stuff
21:24:37 <jgriffith> impossible to scheduler time
21:24:45 <jgriffith> mikal: that's for srue
21:24:46 <ttx> jgriffith: sure. We can have a mix of a half-day to cover several topics, and 40-min sessions to cover specific predetermiend stuff
21:24:57 <rockyg> how about BoFs for topics between end of scheduled day and parties?
21:24:58 <jgriffith> but the other thing we're proposing is no topics without at least POC code
21:25:00 <jogo> jgriffith: yeah that is the tricky part. but I don't know a better time to do that
21:25:11 <clarkb> rockyg: problem with that is by then everyone is dead
21:25:11 <jgriffith> ttx: I like that idea
21:25:14 <jgriffith> mix
21:25:17 <mikal> jgriffith: I've mooted requiring a spec
21:25:25 <mikal> jgriffith: the bucket list thing might mean we water that down a bit
21:25:26 <ttx> rockyg: hat may not be possible dut to arrengements with conference space
21:25:36 <clarkb> rockyg: I think we would like to have something like that but in reality people want to get rid of bags and detox for the day
21:25:45 <jogo> a bunch of issues that we had to sort out at the summit are now solved in specs
21:25:52 <ttx> mikal: there is some risk in keeping the "session proposal" thing but having even less slots to fit them in
21:25:53 <jgriffith> jogo: +1
21:26:00 <rockyg> clarkb:  except the ones who really want to get something ironed out, but then they might be tame enough to come to agreement ;-)
21:26:14 <jgriffith> mikal: so you're saying you've proposed requiring specs?
21:26:20 <jgriffith> mikal: approved or submitted?
21:26:21 <mikal> jgriffith: yes
21:26:25 <mikal> Submitted
21:26:28 <annegentle> feedback I got from Atlanta was that people assumed everyone knew everyone already
21:26:37 <jgriffith> mikal: seems that would go a long way
21:26:42 <jogo> mikal: they should be submitted and contentious
21:26:42 <mikal> annegentle: I heard that from some internal people
21:26:42 <dolphm> informal poll: what percentage of sessions end up being recurring themes summit to summit?
21:26:45 <mikal> I kind of objected
21:26:52 <annegentle> yah mikal
21:26:54 <mikal> I don't want to spend 5 minutes at the beginging of each timeslot doing intros
21:27:04 <dolphm> for keystone, it's about 70-80% ongoing broad topics
21:27:18 <jgriffith> -1 on intros
21:27:19 <annegentle> I think the room layout and joined chairs were the problem there, not intros each session
21:27:24 <jgriffith> time is too valuable :(
21:27:31 <jgriffith> maybe a pre-session meet and great :)
21:27:33 <jgriffith> greet
21:27:36 <ttx> OK how about this strawman: let's drop the "open suggestions for design summit sessions" system and let the PTL handle the schedule in ML disucssions
21:27:38 <dhellmann> annegentle: yeah, we need to be more assertive about just moving the chairs ourselves on the first day
21:27:38 <dolphm> jgriffith: == show up early
21:27:47 <jgriffith> dolphm: exactly
21:27:53 <mikal> ttx: that's an interesting idea
21:28:02 <annegentle> I hate talking about the same issues summit after summit though. Hm.
21:28:02 <markmcclain> ttx: I like that idea
21:28:02 <ttx> side benefit being, less confusion about the summit CFP
21:28:06 <mikal> ttx: it does push a lot of that into email though
21:28:09 <ttx> I know Heat did it like that
21:28:11 <mikal> ttx: which is harder to keep on top of
21:28:12 <ttx> iirc
21:28:19 <dolphm> ttx: that would certainly upset companies that use design summit session proposals to see who gets to go to the summit or not. so ++ because that's dumb.
21:28:19 <jgriffith> ttx: hmm... not a bad idea, although I end up cherry picking anyway regardless of what's proposed :)
21:28:25 <jgriffith> or worse rewriting them :)
21:28:33 <notmyname> personally, I don't like that because basically we'll still end up with submissions that need to be prioritized and scheduled, but now without a tool.
21:28:36 <ttx> mikal: side benefit, you get rid of weird session proposals that don't come from core team
21:28:36 <dhellmann> ttx: so we would ask people to propose on the ML, or they would have to propose to us directly?
21:28:51 <annegentle> ttx: that "no proposals" might just make us look like cliques
21:28:54 <ttx> dhellmann: each PTL would come up with stuff, can be a meeting, a ML...
21:28:57 <notmyname> also, submitting to the ML may (or may not) have a social barrier to those timid about their idea
21:29:02 <jgriffith> notmyname: my belief is if you don't get to it, you handle it in a meetup or other method
21:29:02 <dhellmann> notmyname: I can show you how I use note cards for that... :-)
21:29:05 <dolphm> dhellmann: published a strawman schedule on list and ask for feedback?
21:29:08 <dolphm> publish*
21:29:10 <jgriffith> some topics require more time
21:29:29 <ttx> Also all bear in mind that it's the Kilo PTLs that will do that
21:29:32 <dolphm> dhellmann: i would not recommend starting from scratch; or if you do start from scratch, do so in an IRC meeting with a smaller audience
21:29:32 <notmyname> annegentle: ++
21:29:34 <ttx> poor souls
21:29:37 <dhellmann> notmyname: the social barrier is a good point, though -- we might not have had any discussion of i18n if that had been the rule
21:29:50 <dhellmann> dolphm: makes sense
21:30:04 <annegentle> I do sense we need to recruit to shape what we want, I do
21:30:08 <rockyg> come up with the core topics and schedules and let folks propose topics that fit in with the flavor"?
21:30:24 <jgriffith> notmyname: annegentle OpenStack is no place for the shy
21:30:29 <ttx> annegentle: I just feel like having session suggestions but even less slots to fit them in is setting wrong expectations
21:30:30 <mikal> I'm just going to ask people to brainstorm on an etherpad I think
21:30:30 <jgriffith> just sayin
21:30:38 <mikal> And then sit down with drivers and come up with a plan from that
21:30:38 <dhellmann> jgriffith: but we don't have to make it any harder
21:30:41 <jgriffith> mikal: +1
21:30:43 <annegentle> jgriffith: well, think of it as an extroverted woman who still has to face a sea of extroverted men :)
21:30:46 <sdague> well QA team evolves an etherpad for about a month leading up to the design summit to ensure that certain topics get covered, so is already doing something like this
21:30:48 <jgriffith> dhellmann: I agree
21:30:49 <mikal> It worked for the mid-cycle, therefore...
21:31:00 <dhellmann> mikal: etherpad seems like a good idea
21:31:01 <jgriffith> dhellmann: anonymous etherpad might work
21:31:02 <annegentle> ttx: yes the continual squeezing is not solvable right now
21:31:05 <jgriffith> as mikal just suggested
21:31:25 <dhellmann> jgriffith: if 2 people suggest it, that means we do it, right? :-)
21:31:35 <jgriffith> dhellmann: :)
21:31:39 <annegentle> I discuss what we want at weekly doc team meetings also
21:31:43 <mtreinish> sdague: kind of, mostly it's people put things in the tool
21:31:55 <mtreinish> and then we bug them to add it to the etherpad
21:32:01 <ttx> #info Strawman suggestion: do not use "design summit session suggestion" website this time around
21:32:11 <sdague> mtreinish: the etherpad usually has content before the tool :)
21:32:18 <notmyname> there's always been a lot of confusion of what is submitted where (conference vs summit sessions). we've been pretty good about having a defined process so far about how and when to do summit suggestions
21:32:30 <rockyg> Get new ideas from community through specs that get discussed on etherpads
21:32:34 <ttx> What about the 40-min slots ? Their main goal is to align the schedule with the conference, so that you don't end up missing things because they are misaligned
21:32:42 <mtreinish> sdague: heh, well I guess it depends on the people submitting...
21:32:46 <mtreinish> it's normally a mix
21:33:03 <gordc> what we did in ceilometer was take all the proposals and have all the core members rank the ones they'd want... i think ultimately it's on the core team to figure out what gets selected.. (whether it's their idea or not)
21:33:16 <notmyname> ttx: FWIW, we cut some of those in half in atlanta jsut to fit in a few more. we "manually" managed the timing
21:33:23 <dhellmann> gordc: yeah, I like that, too
21:33:27 <dolphm> having everything predefined might eliminate the confusion about why powerpoint presentations aren't welcome in the design summit
21:33:29 <dhellmann> notmyname: I've done that for oslo, too
21:33:29 <markmcclain> so proposals and selection is only part of it… there is a difference in the people in attendance at the events
21:33:31 <david-lyle> Horizon split almost all sessions
21:33:49 <markmcclain> mid-cycles folks tend to be more in tune with core project direction
21:34:03 <rockyg> how about a design board session for new ideas?  One slot for all to talk about their stuff, then leave the boards for everyone to review?
21:34:07 <notmyname> so, I'd support having official 20-minute blocks that are scheduled, realizing that some sessions will take 2 of them
21:34:17 <gordc> david-lyle: i wasn't a fan of split sessions since it ended up being two rushed topics... did it work well in horizon?
21:34:19 <ttx> I think not having a website-driven CFP will definitely remove some powerpoint
21:34:21 <dolphm> gordc: we did that as well for the few topics that were close calls
21:34:30 <notmyname> gordc: yes, it does make it _really_ rushed
21:34:46 <david-lyle> gordc, for the most part not overly rushed
21:34:56 <markmcclain> ttx: neutron had a no powerpoint rule :)
21:34:56 <david-lyle> not always an equal split either
21:35:00 <sdague> ttx: I think the fixed time block is actually the key issue, because as was brought up in various threads, some topics need airing out. And turns out that only in hour 2 get to something useful. And then other topics that seem to be important turn into "oh, yeh, so we kind of figured that out already, all agreed" and are done in 5 minutes
21:35:11 <david-lyle> I think most of the work needs to be done pre-summit anyway
21:35:20 <annegentle> I think the fixed time block helps with intro/icebreaking/I belong/ etc
21:35:24 <annegentle> er
21:35:25 <rockyg> if you do design board and do it early, you can use stikies to vote like the agile process uses.  Then the most votes at the end also get a session.
21:35:26 <sdague> not that I have any idea how you'd do a 6 track DS without fixed blocks
21:35:27 <ttx> sdague: so, another strawman, we could just have lists of topics we would cover between two breaks
21:35:27 <gordc> david-lyle: cool cool. yeah. presummit work is definitely something important
21:35:27 <stevebaker> we generally have to duplicate the CFP listings into an etherpad to collaborate on, but other parts of the CFP site workflow are nice
21:35:28 <jgriffith> david-lyle: +1
21:35:33 <jgriffith> preperation is key
21:35:38 <ttx> that gives a bit of flexibility
21:35:45 <dhellmann> ttx: how long would those blocks be?
21:35:47 <annegentle> I just said the opposite of what I meant. get rid of super fixed time blocks to help with flows
21:35:49 <jogo> ttx: the issue with that is if folks want to jump between tracks
21:35:54 <ttx> and "some" alignement with conference
21:35:58 <jogo> ttx: but that may be a good tradeoff
21:36:22 <sdague> ttx: possibly, I know in portland we reordered the list a lot to keep flow going.
21:36:25 <dhellmann> jogo: right, we would be constantly chasing devs to get them to come to the oslo room to talk about some cross-project concern
21:36:27 <annegentle> ttx: we don't have room for the "pods" do we?
21:36:29 <ttx> dhellmann: time between start of day and first break, then between break and lunch, then...
21:36:36 <jeblair> jogo: infra only has a handful of slots, but most of us spend _absolutely all of our time_ attending other tracks because of what we do
21:36:37 <dhellmann> ttx: right, but how many hours is that?
21:36:37 <ttx> annegentle: probably not that much
21:36:45 <dhellmann> ttx: rough guess? 3?
21:36:55 <jeblair> so if track-jumping is harder, there may be an impact to our ability to do that.  i'm not sure i'm going to complain :)
21:36:56 <annegentle> 2.5 maybe?
21:37:02 <notmyname> ttx: would that be like scheduling at some conferences (eg pycon comes to mind) where there is a block bounded by a break, and there are a few sessions scheduled in it, but it isn't designed for you to leave half-way through
21:37:02 <ttx> dhellmann: http://junodesignsummit.sched.org/ shows...
21:37:10 <annegentle> if we have the cross-project slots again that'll help?
21:37:15 <ttx> 2/3 sessions
21:37:20 <jgriffith> jeblair: you won't get rid of me in your tracks that easily
21:37:29 <dhellmann> ttx: yeah, so about 2.5 hrs, not too bad
21:37:30 <ttx> 2h20
21:37:43 <ttx> or 1h30
21:38:13 <dhellmann> notmyname: you are actually meant to be able to get up and leave at any point in those blocks, though
21:38:23 <ttx> notmyname: the key benefit is that is one topic needs an extra 10min, that's fine
21:38:33 <notmyname> dhellmann: well, yeah. you can. but I mean that there isn't as long of a transistion between each
21:38:36 <ttx> and if a topic needs 10min left that's fine too
21:38:43 <ttx> less*
21:38:44 <dhellmann> notmyname: true
21:39:16 <notmyname> ttx: right. so schedule longer blocks and keep going until you're done with the topics in that block
21:39:21 <dhellmann> again, maybe some combination? if we have topics we expect to need input from others on, those would have to start a block of time
21:39:30 <ttx> In all cases we'll have the cross-project stuff, and that would probably be organized as 40-min sessions
21:39:31 <dhellmann> and then anything that is team-specific could come after
21:39:42 <ttx> and we'll probably use the design summit suggestion site to get suggestions
21:39:52 <dhellmann> that way other teams would know "oslo is talking about the db library right after lunch" or whatever
21:40:04 <dolphm> how are we going to plan cross-project sessions? mikal's etherpad approach in this meeting?
21:40:22 <ttx> dolphm: tbd
21:40:34 <sdague> dolphm: honestly, that's basically how we did it last time
21:40:46 <ttx> last time it was a TC thing, right?
21:40:50 <sdague> ttx: yeh
21:40:55 <ttx> or a all-PTL maybe
21:40:58 <sdague> about 6 tc member volunteered
21:40:59 <notmyname> ttx: if you want off-the-wall ideas, what about getting rid of per-program tracks all together and just doing cross-project. let midcycle meetups and hallway track handle per-program stuff
21:41:12 <notmyname> not that there aren't (big) disadvantages to that
21:41:15 <dolphm> sdague: iirc, it was a smaller group that did most of the planning. i think that worked out pretty well, but i ended up getting to the summit and kicking myself for not suggesting a couple topics
21:41:34 <ttx> notmyname: that would make midcycle meetups extra design summits, basically.... mandatory presnce
21:41:36 <gordc> dolphm: that's on you.lol
21:41:53 <ttx> that may be the only solution, but i want to explore solutions to avoid that
21:41:57 <notmyname> ttx: yes. but I've already had people asking me why there are 4 swift dev events a year now :-)
21:42:00 <jgriffith> notmyname: do we have enough cross-project to warrant that?
21:42:06 <dhellmann> ttx: should we still keep scheduled times for the cross-project discussions?
21:42:09 <dolphm> gordc: i don't disagree, i just feel like i missed out on visibility into the process somehow
21:42:15 <rockyg> how about an unconference in parallel with the standard sessions?
21:42:24 <jeblair> notmyname: i think the idea is to try to make the summit useful enough to not need mid-cicles
21:42:26 <jeblair> cycles even
21:42:33 <ttx> dhellmann: probably. We'll have several in parallel, some hoping from session to session is a must
21:42:38 <notmyname> jeblair: two week summits? :-)
21:42:41 <gordc> dolphm: agreed. maybe all PTL should be there to have a voice.
21:42:42 <jeblair> at least, not have them be so critically important
21:42:44 <dhellmann> dolphm: now that we've done it once, I think having a larger group with input would work OK, so maybe we should expand it this year.
21:42:46 <jeblair> notmyname: only in paris :)
21:42:50 <dhellmann> ttx: right, that's what I was thinking
21:42:53 <jeblair> notmyname: not in atlanta :)
21:42:59 <notmyname> jeblair: forget that! I'm going to spain after paris :-)
21:43:00 <jgriffith> jeblair: +1
21:43:05 <dhellmann> jeblair: ugh, no, not atlanta, but paris would be ok :-)
21:43:27 <jgriffith> so in all seriousness for a second....
21:43:29 <ttx> design summit 2nd week at my house
21:43:34 <mikal> I don't think mid-cycles exist because of problems with the summit
21:43:38 <dhellmann> ttx: easy sell
21:43:39 <jgriffith> What I'd like to propose for Cinder is requirement of POC code
21:43:41 <mikal> They exist because six months is a long time
21:43:49 <jgriffith> maybe do somethign around time slots
21:43:50 <mtreinish> ttx: +1
21:43:51 <mikal> And projects are more complicated / contentious than they used to be
21:44:07 <jgriffith> but also ideally have an open *day* for informal cinder participants to hammer some things out
21:44:20 <gordc> mikal: agreed. i feel like summit is first stage of vetting, and then meetups end up being second.
21:44:20 <dhellmann> jgriffith: I'm definitely going to require specs this time, but I'm not sure about code
21:44:21 <jgriffith> sort of like unconf, but just "hey, meet over here if you want"
21:44:26 <jeblair> mikal: true, but how much of what happens at mid-cycle could-have/should-have been able to be handled at a summit under ideal conditions?
21:44:30 <notmyname> jeblair: like the ATL pods?
21:44:33 <jgriffith> dhellmann: yeah, I'm torn on that
21:44:33 <ttx> mikal: I would disagree with that. More complex open source projects do very well with 6 months
21:44:38 <notmyname> jeblair: the pods were great for swift in atl
21:44:38 <rockyg> jgriffith: ++
21:44:42 <dhellmann> jgriffith: I see + and -
21:44:43 <jgriffith> kinda depends on what ideas people propose :)
21:44:55 <ttx> mikal: example: kernel summits
21:44:57 <mikal> ttx: are they more directive though? The kernel handles this by Linux being a dictator for example
21:45:13 <mikal> ttx: we have a more collaborative style than the kernel, and I for one like that
21:45:18 <dhellmann> notmyname: ceilometer used them a lot, too, but the oslo team didn't because of being tied up in other teams as well
21:45:44 <jeblair> mikal: in some ways, but it's not like linus decides the features; people still come in with all kind of proposals; it's just one guy gets a global veto
21:45:59 <mikal> jeblair: well, one guy and his team of hench people
21:46:05 <ttx> mikal: I think we fail to reach alignment on goals at the summit, and as we get closer to the end of the cycle, thaat lack of alignment bites us, and it overtakes the whole midcycle meetups which used to just be workshops/hackathons
21:46:05 <annegentle> honestly when docs has had something similar to "midcyle meetup" it was the small group and lack of distractions that made it useful
21:46:10 <mikal> We don't have any concept for subsystem maintainers
21:46:18 <dhellmann> annegentle: +1
21:46:19 <annegentle> but I do think mikal's point is right
21:46:25 <jeblair> ttx: i think that's a good way of putting it
21:46:35 <annegentle> complexity and contentiousness (is that a word?)
21:46:36 <dolphm> annegentle: ++
21:46:37 <jeblair> ttx: there's room to be more effective at the summits
21:46:49 <ttx> In less conflictual projects, they use midcycle gatherings to get things done, rather than to reach the alignemnt they miss
21:46:56 <mikal> annegentle: its a word in Australia
21:47:09 <annegentle> mikal: nice. I'll move there now.
21:47:09 <mikal> I don't think conflictual is a word though
21:47:11 <ttx> and I think that's the most productive setup
21:47:25 <ttx> mikal: it's a word in france.
21:47:26 <notmyname> ttx: I can relate to that for swift
21:47:35 <mikal> Heh
21:47:42 <mikal> So... I think we've stopped making forward progress here
21:47:51 <mikal> I agree that we should try to make summits more effective
21:47:54 <mikal> We have some ideas about that
21:47:59 <ttx> mikal: I don't really seek progress, I seek ideas :)
21:48:03 <mikal> Let's see how it goes and then work out what to do with mid-cycles later
21:48:05 <annegentle> mikal: ++
21:48:31 <ttx> FWIW the Kilo design summit will be organized by the Kilo PTLs, so we can't really all make decisions for them
21:48:49 <jeblair> ttx: that argument is recursive
21:48:51 <ttx> I just want to have options proposed and explored beforehand
21:48:52 <notmyname> ttx: have you considers a website that lets us submit ideas so you can schedule when we talk about them?
21:48:58 <dolphm> but we can tell them what *not* to do :)
21:49:06 <ttx> notmyname: hmm.
21:49:47 <jeblair> ttx: also, kilo ptls should be participating in this meeting :)
21:50:04 <ttx> Side benefit of having time areas with lists of topics to cover, that shall reduce accidental attendance
21:50:17 <annegentle> woops! I attended!
21:50:24 <rockyg> put the ideas on an etherpad, post location to the ml and let people brainstorm.  then collect up the best ideas and discuss.
21:50:31 <ttx> Like "this title looks good, let's show up"
21:50:53 <jeblair> ttx: right, having 40 mins to kill between sessions cuts both ways
21:51:04 <stevebaker> we might need runners to go out and fetch key people to attend micro-topics ;)
21:51:50 <notmyname> so what is the actual problem to solve? efficient use of time? making midcycle meetups superfluous?
21:51:58 <ttx> stevebaker: that's the main drawback. The current scheduling makes sure to reduce overlap between horizontal and vertical programs
21:52:01 <gordc> how about adding tags/keywords to sessions and they can be organized that way? although i guess that puts pressure on ptl to come up with proper tags
21:52:18 <notmyname> just making sure people know when and where to be?
21:52:19 <ttx> by keeping vertical programs in large blocks, and spreading vertical programs all around
21:52:46 <ttx> If we switch to a minimum of 1h30 time slots, we'll create "Heat can't attend QA" symptoms again
21:52:51 <gordc> notmyname: all of the above
21:52:58 <rockyg> ttx: but that really kill cross project collaboration
21:53:44 <jeblair> so i think in that case we have to have a really strong focus on cross-project sessions
21:53:46 <ttx> notmyname: the problem I want to solve is reaching more clarity and alignment at Design Summits
21:53:53 <annegentle> rockyg: I find it really really hard no matter what due to size/scope. We need to invent the time-turner
21:53:58 <dhellmann> jeblair: +1
21:54:01 <annegentle> rockyg: it being cross-project
21:54:09 <jeblair> i think they were really good last time, but honestly, still under-attended; we definitely could have used some more ptls there
21:54:26 <annegentle> ttx: yep that
21:54:32 <rockyg> annegentle:  Im willing to beta test the time-turner!
21:54:36 <david-lyle> I think cross-project work should happen in cross-project sessions, I envision the summits being more about defining the work for the release as a collective upfront and spending time in individual project teams discussing how to best meet those goals
21:55:12 <ttx> More often than not I feel like we are talking about stuff at design summit but fail to come up with a clear consensus, actionable items, and team alignment on release goals
21:55:24 <annegentle> david-lyle: I like this utopia of which you speak
21:55:29 <jogo> david-lyle: oh I like that idea
21:56:40 <ttx> sometims I feel we are trying to cover too much and end up covering nothing
21:56:47 <dolphm> david-lyle: nit: "defining the work" == "herding cats" ... i'd prefer "agreeing on design/solutions" so that when the work does happen (this release or next) we've got something to point to saying "we already discussed how this should look"
21:56:50 <annegentle> maybe summits already are cross project and hence the difficulty due to scope/complexity
21:57:08 <ttx> and part of it is the 40-min slot thing, and some of it is the mass of suggestions we receive with the open CFP
21:57:20 <rockyg> so, how do we merge david-lyles idea and ttxs concerns to reach solid plans?
21:57:34 <ttx> I don't want us to sift through hundreds of proposals while we all know what we should talk about
21:57:51 <ttx> data point, the summit conference CFP received something like 1,200 proposals
21:58:09 <ttx> CFP spamming is a popular sport
21:58:12 <annegentle> ttx: right
21:58:12 <dolphm> and how many sessions did we have, total?
21:58:31 <ttx> i can answer that question
21:58:34 <notmyname> the summit is (1) the only place where all the teams gather and (2) the visible place for attracting new people.
21:58:44 <notmyname> I don't think it fair to say "we all know what we should talk about"
21:59:10 <ttx> 34 slots * 6 rooms (including incubated, "other projects" and cross-project sessions)
21:59:11 <mikal> notmyname: I agree
21:59:12 <notmyname> not using the summit time for cross-project talk seems a waste, IMO
21:59:13 <dhellmann> notmyname: yeah, I know that's not the case for oslo.
21:59:18 <annegentle> notmyname: agreed
21:59:20 <mikal> Summit is more cross project than mid-cycles
21:59:27 <notmyname> and making it easy for new people to participate seems important
21:59:28 <mikal> And the cross project stuff is important too
21:59:38 <mikal> Even if it distracts from just delivering the latest release of project X
21:59:43 <notmyname> mikal: in fact, our midcycle meetups have the rule "no intro to swift" topics
22:00:01 <mikal> notmyname: the nova ones don't even do background info...
22:00:08 <dolphm> wow, so we end up rejecting or merging over 80% of the session proposals?!
22:00:12 <mikal> notmyname: its straight into "what's wrong with migraion 128 and how do we fix it"
22:00:18 <notmyname> mikal: right.
22:00:26 <ttx> dolphm: that 1,200 figure is for the summit conference-sideCFP
22:00:53 <dolphm> ttx: oh, not design summit proposals?
22:01:00 <ttx> we had about twice as much proposals than we had slots. But I expect the numebr of proposals tto go up.
22:01:09 <ttx> since Paris is popular
22:01:19 <ttx> and getting your stuff accepted can be your ticket to go
22:01:26 <ttx> and we are off tim
22:01:26 <notmyname> ttx: yup
22:01:27 <ttx> e
22:01:38 <notmyname> ttx: where do we continue?
22:01:43 <notmyname> the conversation?
22:01:44 <ttx> so we should expect a surge in proposals if we keep the web-driven CFP
22:01:51 <ttx> notmyname: I'll raise a new thread
22:01:59 <ttx> so that we can continue exploring options
22:02:14 <ttx> Thanks everyone, that was a good talk
22:02:18 <ttx> #endmeeting