21:03:15 #startmeeting project 21:03:16 Meeting started Tue Aug 12 21:03:15 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:03:20 The meeting name has been set to 'project' 21:03:22 Agenda for today is available at: 21:03:22 Hi 21:03:27 #link http://wiki.openstack.org/Meetings/ProjectMeeting 21:03:53 #topic News from the 1:1 sync points 21:03:58 We covered all projects but Cinder this week (Cinder is having their midcycle meetup) 21:04:02 Here is the log: 21:04:05 #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-08-12-08.03.html 21:04:57 In summary all projects are slightly behind schedule, and most of them will use FPF to drop stuff that is not proposed next Thursday 21:05:04 #topic Other program news 21:05:09 Any other program with a quick announcement ? 21:05:23 o/ 21:05:28 o/ 21:05:38 I have a quick psa that ties into the later agenda item; I can wait until then 21:05:52 I will be switching everyone to trusty by default on the 20th and updating tox 21:06:03 clarkb: nice 21:06:14 clarkb: trusty FTW! :) 21:06:33 ttx: we want to move stackforge/kite to openstack/kite since it was adopted by barbican 21:06:48 ttx: do you sync with jraim? 21:07:04 I can do thaht 21:07:28 we were also wondering about python-kiteclient 21:07:36 it should probably move as well 21:07:46 but then it's not like an emergency repomove 21:08:35 they should stay together, for sure 21:08:36 jeblair: won't be that much around in the coming days 21:08:49 jeblair: you got a repomove day planned? 21:09:12 ttx: yeah, saturday. we'll try emailing him i guess :) 21:09:44 ack, thx 21:09:54 ok, moving on 21:09:57 #topic When to open Kilo specs (mikal) 21:10:03 mikal: ohai 21:10:06 Heya 21:10:16 So... I'm receiving questions on when specs for K will open 21:10:17 I know mestery wanted to discuss that as well 21:10:19 * mestery listens closely here. 21:10:22 ttx: ++ 21:10:25 why are specs not open now? 21:10:29 Given we'd said that the specs process would be more synced between projects in K 21:10:39 I feel like we should have a unified plan for this as well 21:10:40 bump any still-open juno specs to kilo now? 21:10:53 We'd felt that working on specs now was a distraction from landing J 21:11:02 I think the main concern is the review overload. But then you could train reviewers to ignore Kilo specs until Kilo opens 21:11:05 However, I now realize the people writing specs have little interest in fixing J bugs 21:11:14 mikal: It's a tough nut to crack 21:11:15 i don't have an example today, but if we had review bandwidth and a spec proposed to a kilo/ dir today, why not give it a review? is there reason to block it? 21:11:19 i.e. the people wanting to do one now are people only interested in landing their feature 21:11:23 esepcially since they should not really be looking into *-specs at this point 21:11:59 mikal: what are you trying to stop people from doing? proposing kilo specs? reviewing kilo specs? landing them? 21:12:00 but the fact that they can't propose to gerrit won't stop them working on their spec surely? 21:12:01 So I guess this was more of an informational thing 21:12:06 dolphm: I think you don't have the same type of problems that Nova, Neutron (and possibly Cinder) have 21:12:07 What are other projects doign for this? 21:12:19 where the sheer noise is disturbing 21:12:24 dolphm: distracting reviewers, and attempting to redirect that effort into things we need for J 21:12:28 people only want to write specs? 21:12:36 ttx: certainly! 21:12:38 annegentle: yes, some people 21:12:42 mikal: or is it that they want assurance _all_ will land? 21:12:43 annegentle: but write them and reviewers will come 21:12:48 mikal: can't reviewers just ignore kilo/ specs willingly? 21:12:51 mikal: as in spec,code, everything? 21:12:56 We have vendors who have little interest in fixing bugs, and only care about landing their feature 21:13:04 mikal: I was thinking of just bumping all open juno specs to kilo and then asking the review team to use their judgement as to where to apply their review cycles 21:13:06 It's hard for us to focus on Kilo spec reviews when we're still trying hard to land Juno stuff. 21:13:11 mikal: they'll write specs but not docs, and that needs to be nipped 21:13:14 dolphm: sure... its more the attempt to redirect the author's efforts that we were after 21:13:17 the sheer noise is distracting <--- this 21:13:20 mikal: ... with a heavy steer away from kilo specs, but not enforced 21:13:44 folks show up in IRC pushing the "please review my spec" button over an over again 21:13:45 I don't think moving J specs to K is a good idea for nova 21:13:50 We have a lot of abandonded specs as well 21:13:51 mikal: but like you said, certain spec authors couldn't care less about stabilizing the previous release, especially if they're feature isn't in it 21:13:52 devananda: ++ 21:13:55 Re-proposing is light weight 21:14:11 dolphm: sure, but I was trying to change their behaviour 21:14:15 dolphm: it didn't work 21:14:16 devananda: I use a mental /ignore to filter those :) 21:14:17 mikal: cats 21:14:37 So, it sounds like other people are allowing K specs now? 21:14:51 for ironic, my plan is to -2 all open specs, then wait until some time (exactly when TBD) after FF before creating the /kilo directory, and then see who reproposes 21:14:52 mikal: Not Neutron. 21:14:59 mikal: how about moving abandoned specs into an abandoned/ dir at the end of a release, all at once? 21:15:16 dolphm: we were just goign to -2 in gerrit like devananda 21:15:26 dolphm: moving them into a dir would require merging them 21:15:31 Which would be a lot of reviews 21:15:35 Unless its one super review I suppose 21:15:45 devananda: design discussions should still go on - i don't think a -2 is particularly beneficial to anyone 21:16:00 mikal: I'm not a huge fan of attempting to force the hand of developers, as they tend to just workaround the restriction in any case 21:16:04 annegentle: all those who write specs won't really be around to write docs :) 21:16:08 dolphm: the review needs to have its paths chagned, hence the procedural -2 21:16:12 mikal: you're talking about abandoned reviews then? 21:16:22 dolphm: yeah, largely 21:16:32 It's tricky, you want to let the door open but clearly show that it's frowned upon 21:16:35 dolphm: we don't know what's abandoned at the moment, as spec review stopped a while ago 21:16:42 dolphm: that's exactly it. i DONT want design discussions happening between now and RC 21:16:46 so that people know they should be usig their time doing something else at this point in the cycle 21:16:49 dolphm: do asking people to rebase is a way they signal that they still care 21:16:52 at least not in as much as they take away from making a stable RC 21:17:07 s/do/so/ 21:17:23 devananda: ++ 21:17:24 positive steer beats negative restrictions, IMO 21:17:32 there are seriously only two things in ironic that deserve an ongoing discussion with cores - and we already have that informally 21:17:44 devananda: that seems like you're shooting yourself in the foot 21:18:10 devananda: (trying to artificially inhibit design discussions) 21:18:33 dolphm: focusing on one thing for a short period of time means putting other things on the back burner 21:18:36 I don't see how that's a bad thing 21:18:37 eglynn: how would you present it in a positive way while still discouraging out-of-sync actions like this? It's tricky 21:19:01 devananda: normally, what we're designing for and what we're doing are closely related 21:19:03 dolphm: we'll definitely have those design discussions with vendors and interested parties, after we do the work needed to get Juno out the door 21:19:04 ttx: the value proposition is making juno a release we can be proud of / can stand over etc. 21:19:28 eglynn: I haven't had a lot of joy with that sort of angle 21:19:38 eglynn: "do reviews, it will speed up your own review by making the queue smaller" 21:19:42 eglynn: zero reviews occur 21:19:58 mikal: fair enough, much bigger and more diverse contributor base in the nova case 21:20:12 mikal: ... social pressures easier to apply with a smaller group 21:20:19 eglynn: as someone who has been asking people to work on RC bugs for the last 9 releases, i would say that the beauty of the game is not a sufficient motivator 21:20:20 eglynn: I think that's very true 21:20:33 eglynn: also, it seems projects with a vendor driver layer seem to have a harder time 21:20:41 mikal: fair point 21:20:47 it only touches a minority of contributors, the "strategic" ones 21:21:30 ttx: ... if all else fails, one can always try "guilting" them into doing it :) 21:21:36 I don't feel like we reached a concensus here 21:21:52 So. solution one is to not prevent K specs from being submitted, and teach core reviewers to ignore them 21:22:03 mikal: what was the question, again? 21:22:07 solution 2 is to somehow prevent those from being filed until RC1 21:22:13 mikal: well a one-size-fits-all approach may not work across all the projects 21:22:21 ttx: I am increasingly of the believe we should go with 1 21:22:25 eglynn: it's definitely not a one-size-fits-all 21:22:33 Yeah, agreed 21:22:34 it's finding a solution for the largest projects 21:22:46 ttx: that's fair 21:22:51 dolphm: whether opening K specs now is a mistake 21:22:52 Ignoring specs has it's own issues, if that's a solution it's the wrong one. 21:22:57 We hit many issues with that in Neutron during Juno. 21:22:59 mikal: i prefer solution 1. Solution 2 is only pretending to fix the issue 21:23:07 ttx: agreed 21:23:10 If anything, being more proactive about responding to specs is the right approach, but that requires time. 21:23:26 Its ok, K will be full of magical runways of awesome 21:23:29 mikal: well then i vote that closing them was a mistake :) 21:23:40 We just have to get there with no one getting murdered on the way 21:23:56 mestery: you think we can't just say "K specs will start getting reviewed when K development opens" ? 21:24:08 that sounds like something that rings true, somehow 21:24:11 ttx: My experience shows people get angry when their specs are ignored. 21:24:14 ttx: that's what nova originally said 21:24:20 While it's a fair statement, not everyone will be happy with it. 21:24:24 ttx: and what happens now is everyone pings me and says they're sulking 21:24:25 mestery: when anything in gerrit is ignored 21:24:31 dolphm: ++ 21:24:33 ttx: and declines to work on bugs instead 21:24:39 sigh 21:24:41 mikal: I get that too 21:24:52 I get a lot of very weird personal email 21:25:04 mikal: we should trade some 21:25:12 ttx: have a gallery of the best? 21:25:25 mikal: I bet not as weird as mine 21:25:34 sounds like a topic for a beer 21:25:39 Maybe neutron / cinder / nova should collude for a "big project plan" 21:25:50 We could have a quick chat when John gets back 21:25:52 mikal: ttx: just reply on an mailing list 21:25:53 mikal: :) 21:26:18 It seems like the big project concerns aren't shared by the smaller projects 21:26:25 I'm back :) 21:26:27 dolphm: I reply to a lot of email asking them to resend it to the -dev list 21:26:29 Oh, that guy 21:26:30 mikal: right that's my sense of it too 21:26:44 dhellmann: i just do that for them :) 21:26:50 frankly, I think if you have so many people that don't care about your project that you can't get enough "normal" work done, you have a separate problem 21:26:53 doesn't happen all that often to me though 21:26:57 mikal: i'm sort of surprised, given how much ironic's concerns overlap with nova's 21:26:58 this K specs thing is just a symptom 21:26:59 ttx: oh, agreed 21:26:59 ttx: ++ 21:27:05 mikal: I don't consider us a large project, tho 21:27:10 ttx: definitely 21:27:14 ttx: is more about trying to push the distraction laser out of the path of the people who are part of the solution 21:27:16 could we not just have a gerrit autoresponder for projects that want delay that includes a note of when the opening will occur? 21:27:42 devananda: surprised that smaller projects seem less concerned you mean? 21:27:42 mikal: in the end, it's "how to avoid the PTl pain of dealing with unreasonable requests" 21:27:50 markmcclain: it wouldn't even need to be a bot, it could be a check job 21:27:53 I think jgriffith wrote a book on it 21:28:09 ttx: I think that pain is unavoidable 21:28:14 ttx: because we deal with humans' 21:28:22 mikal: surprised that smaller proejcts don't share the concerns of larger projects (+ ironic) 21:28:27 mikal: we could do a better job of communicating expectations though 21:28:28 ttx: I tried building a core reviewer out of lego, it didn't work out so well 21:28:54 ttx: well, we did announce that we would freeze specs, accept no K specs, and fix bugs 21:29:03 ttx: people just don't like it so they complain and don't fix bugs 21:29:17 mikal: that's awesome 21:29:23 I think you do as much as you can, we (as in me) need to ramp up developer docs and training to match 21:29:24 mikal: that would be my fear exactly 21:29:28 there's a group working on getting corporate project managers more involved, maybe communicating these expectations is an area where that would be useful? 21:30:06 dhellmann: if I had a mailing list of corporate project managers I could email asks to, I would use it a lot 21:30:08 ttx: a big page that answers the question "as a contributor, what should i be working on this week?" would be dandy 21:30:12 mikal: at this point it's like they are just not contributing, so you shouldn't count on them for bugfixing 21:30:18 dhellmann: "please encourage your people to focus on bug fixes for now" 21:30:26 you may have a smaller set of contributors than you think :) 21:30:27 ttx: and by big page, i mean like a giant link to gerrit 21:30:33 ttx: agreed. I also don't love drive by features by the way. 21:30:34 I think as PTLs we already act as project managers, I don't think developers would necessarily listen to other ones either. 21:30:35 * eglynn thinks we've got to get out of the mindset that we can *tell* devs what to work on ... at most we can steer and incentivize IMO 21:30:38 ttx: which is what a lot of this is. 21:30:38 bug fixes and document the features that did land. 21:31:03 mikal: zehicle and sarob are involved in that, according to their blogs (also allison randall, but I don't know her irc handle) 21:31:16 eglynn: that's probably true, although I don't know how to get there from here (at least in nova) 21:31:35 mikal: once upon a time, everyone was attening the "project meeting" (this one) and just me shouting at people what enough to communicate cycle priorities 21:31:49 s/what/was 21:32:03 dhellmann: wendar 21:32:04 we grew to the point where only PTLs attend this meeting 21:32:09 devananda: thank you 21:32:10 and they know the priorities 21:32:21 ttx: ah the good old days 21:32:26 dhellmann: these new corporate project managers would have how much leverage over the developer resources, do you think? 21:32:30 * mordred didn't attend this meeting even back then 21:32:35 * mestery reminisces. 21:32:39 So, I feel like we should move on 21:32:41 mordred: ha 21:32:46 There are other things on the agenda 21:32:48 And this has stalled 21:32:50 mikal: ++ 21:33:00 #action ttx to think about how to communicate cycle priorities in the thousand-contributors times 21:33:00 mikal: ++ 21:33:02 eglynn: well, it wouldn't be a matter of saying "we need you to do X" at first, but a matter of saying "don't talk to us about new features for a few weeks, we have bugs to fix" 21:33:15 eglynn: setting expecatations at a different level in the organization 21:33:30 devananda: yeah, cool enough if it's "soft steer" like that 21:33:50 dhellmann: ^^^ 21:33:54 mikal: in summary, i think you should keep K specs open. We need to communicate cycle priorities better, but that's a bigger issue 21:33:57 darned tab completion! 21:34:18 ttx: yeah, that's where I got ot as well 21:34:33 ttx: I will discuss with John when he gets back from his cold meat themed music festival 21:34:33 this meeting, and occasional ML rants are no longer enough 21:34:38 * devananda disagrees, keeps K specs closed 21:34:45 devananda: as is your right 21:34:48 devananda: ftw 21:34:56 ok next topic 21:34:58 #topic Clarification on documentation contrib workflow (eglynn/annegentle) 21:35:00 i'll let ya'll know how it goes when we get to paris 21:35:06 Heavyweight XML-based docbook versus new lightweight RST-based model 21:35:07 yeah, just something I wanted to raise on the PTLs' radar 21:35:09 Fight! 21:35:20 as it could save your team some learning curve 21:35:23 heh no fight here 21:35:29 (if your project has substantial docco contribution coming down the road) 21:35:29 eglynn: presented like this, i can't side with XML 21:35:41 annegentle: agreed, all sweetness & light! :) 21:35:59 ttx: this is more in the line of a PSA 21:36:00 Could we perhaps use microsoft word for docs? 21:36:04 so basically there are now two separate contrib models for doc 21:36:04 next I will require video documentation 21:36:15 * annegentle stabs mikal with a spork 21:36:20 Heh 21:36:30 the XML-based docbook has a significant learning curve 21:36:43 but the docs team is piloting a new lightweight option 21:36:56 based on RST that we all know and love :) 21:36:58 annegentle: sporks are too sharp 21:37:14 so given how enthusiastic devs are for writing kilo specs in RST 21:37:24 xml used to be keystone's primary means of api docs, and we got less than zero community contribution. moving to MD/RST, we get quite a lot, although RST is still apparently a challenge to get even close to correct for most people 21:37:25 eglynn: heh quite the tie in 21:37:52 yep, seems that they should also be gunning to knock out the docco in the same format 21:38:16 annegentle: have I represented all that correctly? 21:38:22 eglynn: now I'm disappointed. I'm addicted to conflict now 21:38:37 ttx: LOL :) 21:38:43 yes, though currently we are doing a POC with Heat only 21:38:50 part of this psa is also that I've got patches removing WADL from the "long form" API documents 21:39:00 dolphm: https://review.openstack.org/#/c/112620/ 21:39:26 that helps with the problem of broken doc builds across repos (where the WADL breaking would break another repo's build) 21:39:39 Is someone going to move the existing XML docs to RST? 21:39:41 what I'd like to do next is propose RST for the "long form" info that's left, like rate limiting, etc. 21:39:50 Cause that person will look awesome on stackalytics 21:39:54 die WADL die 21:39:56 mikal: this is a phased approach 21:40:12 mikal: well that person is me and I still won't match someone like Andreas Jaeger :) 21:40:36 Heh 21:41:04 annegentle: my hero! 21:41:06 mikal: the phases are: POC for Heat (HOT Template), WADL removal for only docs on http://docs.openstack.org/api/api-specs.html 21:41:38 then RST proposal for API docs in each repo 21:41:39 annegentle: so for kilo, will the RST model become the primary vector for doc contributions from the project teams, d'ya think? 21:41:42 any questions? 21:41:46 annegentle: so, related conversation... should identity-api still exist? or should it be somehow merged into keystone-specs? 21:41:51 (or over a longer time horizon) 21:42:07 WADL remains our only solution currently for http://developer.openstack.org/api-ref.html but I'd welcome ideas 21:42:09 annegentle: are you using sphinxcontrib-pecanwsme for API docs for new projects? should I get that moved to stackforge? 21:42:29 dolphm: I was going to propose it in keystone, but maybe in -specs is the better way? 21:42:50 dhellmann: I don't have a solution for extensible apis like nova neutron keystone right? 21:42:54 annegentle: doing it in -specs allows us to see proposed API changes as part of the design process 21:43:17 dolphm: right but you're the only team doing that, so my thinking is that I shop it with patchsets 21:43:33 dolphm: or I guess I could do ML post prior to patchsets 21:43:36 annegentle: yeah, this would just be for new stuff, I'm just curious if you're actually using it in some way for non-developer docs since it's still under Dreamhosts' github account 21:43:55 eglynn: as for "will the RST model become primary vector" -- I have a dependency on a page-based redesign 21:44:03 annegentle: i'm asking selfishly here, knowing no one else uses keystone's process 21:44:12 for api documentation, anyway 21:44:16 annegentle: fair enough 21:44:24 dhellmann: I really would prefer a single API reference "way" -- swagger, raml, wadl, whatever 21:44:41 dhellmann: how you generate it I don't care 21:44:48 rst + jsonschema definitions :) 21:44:51 dhellmann: unless it's crappy 21:44:52 or md 21:44:53 annegentle: ok, I wasn't pushing a solution, just wanting to make sure the tools you might be using were easily fixable as needed 21:45:25 dhellmann: seems like it 21:45:39 I suspect most projects are going to be using some JSONSchema thing anyway, so the wsme doc lib might not be as useful 21:45:52 dhellmann: it looks like that's the compute v3 api (jsonschema) 21:45:57 yeah 21:46:01 right 21:46:18 ok, I think the PSA is now emitted 21:46:20 I still believe a lot of discussion about scope will help the docs program 21:46:28 There is no v3 api by the way 21:46:31 since all of this overflow is in integrated projects 21:46:31 It was a mirage 21:46:35 oh yes v3 / v2.1 21:46:43 Ta 21:47:17 eglynn, annegentle ready to move to open discussion? 21:47:19 https://review.openstack.org/#/c/85640/ for the curious/uninitiated 21:47:26 I'm good-to-go if eglynn is 21:47:26 ttx: yep 21:47:43 #topic Open discussion 21:47:43 annegentle: thanks for all the additional background detail 21:47:47 Anything else, anyone ? 21:48:18 someone come up with something so ttx doesn't get an early meeting end! I kid, I kid. 21:50:44 tss 21:50:46 #endmeeting