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