21:01:36 #startmeeting crossproject 21:01:37 Meeting started Tue Sep 22 21:01:36 2015 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:40 The meeting name has been set to 'crossproject' 21:01:53 \o 21:01:55 courtesy ping for david-lyle flaper87 dims dtroyer johnthetubaguy rakhmerov 21:01:55 courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle 21:01:55 courtesy ping for adrian_otto mestery kiall jeblair thinrichs j^2 stevebaker 21:01:55 courtesy ping for mtreinish Daisy Piet notmyname ttx isviridov gordc SlickNik 21:01:55 courtesy ping for cloudnull loquacities thingee hyakuhei redrobot dirk TravT 21:01:55 courtesy ping for vipul lifeless annegentle SergeyLukjanov devananda boris-42 nikhil_k 21:01:59 o/ 21:01:59 o/ 21:02:00 o/ 21:02:02 o/ 21:02:03 hi everyone! 21:02:03 o/ 21:02:03 o/ 21:02:05 o/ 21:02:07 o/ 21:02:12 o/ 21:02:16 O7 21:02:18 here 21:02:19 Agenda: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting 21:02:25 o7 21:02:28 o/ 21:02:30 \o 21:02:31 o/ 21:02:35 #topic review past action items 21:02:42 Hi 21:02:54 #info Add string freeze to common cycle with milestones merged thanks to johnthetubaguy and TC! 21:03:07 #link https://review.openstack.org/#/c/223011/ 21:03:15 #info Base feature deprecation policy merged thanks to ttx and the rest of TC! 21:03:27 #link https://review.openstack.org/#/c/207467/ 21:03:43 Yeah, I'll be in touch with PTLs to explain if and how they should assert it 21:03:56 #info Return request ID to caller merged thanks to Abhishek and TC! 21:04:03 #action ttx to communicate about base deprecation policy 21:04:14 #link https://review.openstack.org/#/c/156508/ 21:04:16 well, the tC just put the stamp on that one, no credits 21:04:32 Abhishek should get all the credit 21:04:37 o/ 21:04:54 ttx: yes will sync 21:05:16 lifeless: lets talk about avoiding using testr in environment under test 21:05:19 #link https://review.openstack.org/#/c/218070/ 21:05:40 I would like to say thank you to everyone who helped in getting the spec "Return request Id to caller" approved 21:05:51 I think we're still in the same place from last cross project meeting? 21:05:56 thingee: we talked last week; its on me to get more refinement 21:06:14 thingee: I've been working the backwards-compat-and-branchless stuff this week 21:06:18 tpatil: that was a long effort, thanks for sticking with it 21:06:59 got it, ok, we'll circle back next week? 21:07:00 dhellmann, Thanks. I have few questions about next steps which I would like to discuss in Open discussion 21:07:06 lifeless: ^ 21:07:27 abhishek, tpatil Thank you. It *will* be extremely helpful moving forward 21:07:31 ok! 21:07:38 #topic Team announcements (horizontal, vertical, diagonal) 21:07:47 On the release management front, we are 3 weeks before the end of the liberty dev cycle 21:07:56 We are chasing the last FFEs which should have been merged a long time ago 21:08:01 We started issuing RC1s today 21:08:06 Most projects should issue those this week 21:08:18 Rockyg: Thanks 21:08:21 Intermediary-released projects (like swift and ironic) are expected to release a likely-final Liberty version before end of month as well 21:08:26 ttx: do you want a releases review for the rc1 commit? 21:08:39 #info release management says 3 weeks before end of the liberty dev cycle 21:08:43 stevebaker: no. I do have an "open-mitaka" commit though 21:08:45 I believe we've finished all the library releases and stable branches for this cycle, but if you manage one that I missed please get in touch with me 21:09:00 thingee: yes, hopefully ;) 21:09:01 #info release management: RC1s have started today! 21:09:03 stevebaker: see https://review.openstack.org/#/q/branch:master+topic:open-mitaka,n,z 21:09:10 Starting now don't hesitate to flag things that may impact the final release(s), especially cross-project issues, in #openstack-relmgr-office 21:09:37 do these coverage 4.0 changes need to be in the rc1s? https://review.openstack.org/#/c/225736/1 21:09:52 mordred: ^? 21:10:01 so, would this be a good time to ask why a new development cycle needs a major semver bump? :) 21:10:03 I think that's more forward-looking... mordred ? 21:10:21 #info release-management: don't hesitate to flag things that main impact final release, especially cross-project issues in #openstack-relmgr-office 21:10:27 I asked this earlier and the answer was "that's what most projects seem to want" 21:10:38 jroll: it doesn't, for intermediary-released projects 21:10:39 but it's not really semver, so I just wanted to throw the question out there 21:10:49 I would put coverage fixes in releases so coverage works but its not required to releease aince the joba run post merge 21:10:56 ttx: I'm asking in general, not about ironic specifically 21:11:00 see swift, they don't bump X on cycle boundaries 21:11:16 arro? 21:11:22 ttx: asking because we say "now we're doing semver" but we aren't actually doing semver 21:11:25 jroll: it's a bit of an artifact from pre-versioning 21:11:38 jroll: which we may get rid of early next cycle 21:11:40 stevebaker: it's only urgent if you have gating on your coverage tests working 21:11:42 jroll: I think ttx is saying that projects may choose, and likely both swift and ironic will choose _not_ to bump major version number on release cycle boundaries 21:11:52 stevebaker: if you do not have gating on coverage, then you can land those whenever 21:11:57 whereas other projects will choose to do that 21:12:08 mordred: ah. we don't and I wish we did 21:12:13 stevebaker: although, if you land them now, it gets them off of y gerrit screen, which make me happy 21:12:20 devananda: rephrased, my question is "why are projects not doing semver right" :) "because that's their choice" is a fine answer 21:12:44 ok, anything else for announcements? 21:12:50 jroll: that also seems to be the actual answer 21:12:59 jroll: so to answer your initial question, no it's not a good time to ask *now*, as we are deep down in the middle of the process 21:13:08 thingee translation reviews 21:13:16 for keystone looks like we can remove eventlet support since it was deprecated 21:13:20 they should get into RCs 21:13:24 but asking at the start of the next cycle is a good thing :) 21:13:32 ttx: sure, thanks 21:13:39 ahh, yes, wet all your rubber stamps, there are translation reviews awaiting 21:13:50 topic is zanata/translationd 21:13:58 er zanata/translations 21:14:23 clarkb: new rules for StringFreeze (from johnthetubaguy) are that we give them a week post RC1 to merge them into a RC2 21:14:40 clarkb: https://review.openstack.org/#/c/223011/ 21:14:41 basically translators finalize translations based on the RC1 drop 21:15:03 but yeah, they are coming in 21:15:09 do translations go into master? 21:15:15 bknudson: I was about to ask that 21:15:30 afaik yes 21:15:41 today its master only, yesterday we got asked to aupport the release branches too 21:15:43 if they go to master, most will be lost and require hackish scripts from AJaeger to backport 21:15:47 I am working on that 21:16:11 clarkb: check with AJaeger he had the magic script to sync only relevant things 21:16:13 clarkb: is there still a % threshhold below which the translation bot won't propose it? 21:16:21 ttx ya he has reviewed 21:16:27 devananda yes 21:16:56 ok great, going to move on... 21:17:16 #topic Making the cross-project meeting more useful 21:17:19 so this meeting... 21:17:53 Anne Gentle brought up the thread of asking how we could make this meeting more useful http://lists.openstack.org/pipermail/openstack-dev/2015-September/074521.html 21:19:02 I think the basic breakdown is, in this meeting we ideas proposed that just aren't ready to be discussed here sometimes. Mainly because the right people haven't commented on a spec. 21:19:15 we have ideas proposed* 21:19:48 it's hard to get behind a x-project spec that you don't know if every project is going to accept it. 21:20:01 or that it's going to take so long to implement that it might never be done 21:20:08 That brought light to the purpose of the product working group, which likes to follow these cross project ideas, and ensure the right projects are aware of them and give thoughts on those ideas. This helps with the idea of a spec for example becoming stale, or not getting the right attention. 21:20:40 e.g., if you have a 50% chance to get into nova and 50% chance to get into keystone, etc., pretty soon there's a ~0% chance it's done. 21:21:38 thingee: one aspect of it is that some of those specs aren't really glamorous, but sometimes just plumbing 21:21:56 so hard to see as part of a key objective or a larger vision 21:22:32 http://specs.openstack.org/openstack/openstack-specs/ 21:22:37 ensuring any discussion is prefaced with a larger vision is helpful 21:22:42 is the question what we can do to be better, or that something is broken now that we need to fix? 21:23:13 notmyname: you put my thoughts extremely well above 21:23:21 notmyname: my feeling (which I expressed on the thread) is that it's broken -- it's really a painful experience to drive something through that process 21:23:56 ttx: the cross-project spec process? or are we talking about making this meeting betteR? 21:24:02 ttx: but does that break x-project meeting or just x-project specs? 21:24:09 a related note is http://lists.openstack.org/pipermail/openstack-dev/2015-September/075129.html which indicates that our cross-project discussions really are a foreign language to at least some entrenched developers in our community 21:24:13 yeah I think things got derailed a bit. Let me try again... 21:24:36 a lot of boring work is hard to get reviewers of it. 21:24:38 notmyname: thought you were talking about the xproject specs process. 21:24:46 fungi: y i tried explaining :) 21:24:50 the release / spec process is geared towards adding new features. 21:25:09 So from what I was getting from this thread, how can we make this meeting better. 21:25:19 no, sorry. I thought the topic was about this meeting 21:25:38 I think sometimes we're not ready to have this meeting. The proposed specs still need attention or a good solution 21:25:39 notmyname: as far as the meeting goes, I feel like it fails to be used as a way to have direct discussions on cross-project issues. Almost nobody adds topics to discuss 21:25:39 the thread is about all the channels and the outcomes we need from cross-project work. 21:25:54 oh hi annegentle ! 21:25:54 this meeting being "a channel" 21:25:58 * annegentle waves 21:26:02 thingee: we aren't ready, or agenda items aren't ready? :) 21:26:11 agenda items aren't ready 21:26:26 thingee: I think we need to encourage only adding things to agenda if they're ready for discussion, or someone wants confirmation it's a thing they should work on, or whatever 21:26:33 so I've given thought on the process for ideas that become cross project can come to light in this meeting http://lists.openstack.org/pipermail/openstack-dev/2015-September/074867.html 21:26:39 my proposal^ 21:26:41 for cross-project you really need some backing that it's a good idea early since it's going to be a lot of work 21:26:51 ++ 21:26:56 so I think it's a good idea to bring half-baked ideas here 21:27:11 ttx: I'd like to disagree ... this hour is extremely valuable at least for me to keep up what's going on around as I genuinely don't have time to crawl through the mailing list or spec repos to figure that out 21:27:35 well, and also that there are likely to be others who will help you convince all the various projects involved that whatever you need their help to get implemented is really worth the effort 21:27:36 jokke_: I'll be answering that bit of keeping up with the ML later :) 21:27:45 to me a meeting lets you get more real-time input and feedback 21:28:28 So the main point of my proposal is cross project idea discussions should not be on IRC, ML, here and there. 21:28:32 yeah, I'm personally ok with topics in this meeting being "is this crazy?" but not "let's review this spec in real time" 21:28:49 it makes conversations difficult if you have to know where some people's views are in different places. 21:28:59 The first proposal is encouraging discussion to stay in the spec 21:29:03 in gerrit 21:29:10 jokke_: that's good fedback thx 21:29:14 +e 21:29:16 thingee: +1 21:29:18 jroll: +1 21:29:23 thingee: I think there's value in finding out if everyone hates the idea before writing the spec :) 21:29:32 ++ 21:29:58 thingee: if we *do* want to solve that case outside of the meeting, the initial spec could just be the first section or two, to see if it should proceed further. or we could just spend 5 minutes on it here 21:30:01 jroll: right! so going back to my first thing on the proposal, the idea starts on the ML, or a single project patch 21:30:22 assuming that's good, all discussions are encoruaged to stay in the gerrit review spec 21:30:26 jokke_: yeah, the key aspect being you have a predetermined agenda that lets you decide if it's worth attending / staying up 21:30:36 This meeting is really good to see where we are and provide some direction, but I think that cross project specs might benefit from a "virtual sprint" of interested people to focus on getting it past initial phase and into ready for "meeting" discussion 21:31:01 thingee: sure, but like annegentle said, it's much quicker feedback here. I'm fine with either way but she does have a point :) 21:31:09 are we saying the meeting is only about specs? 21:31:17 ttx: that and I do have this slot booked in my calendar to catch up what's going on rather than trying to "justify" that time from something else through the week 21:31:17 jroll: on the other hand, it may be pretty quick to push up a one-paragraph placeholder/wip spec and ask for input there 21:31:24 jroll: right, so my main point of wanting to do this, is so that these meetings become more interesting to people. 21:31:30 the problem is not everyone attends this meeting. 21:31:38 fungi: yep, I mentioned that, I'm good with that 21:31:41 I think that might have to do with the fact that progress is kind of slow here. 21:31:46 things aren't ready 21:31:49 so people get bored 21:32:15 jroll: indeed. i should have read further before responding 21:32:28 :D 21:32:31 * Rockyg is starting to get bored...just kidding! 21:32:39 instead, if we had specs in more of a consensus point, these meetings would be fewer because of the number of topics that get to that point, and makes the meeting more interesting when there are stuff to look over. 21:32:40 haha 21:33:00 thingee: well, it often takes > 1 cycle just to get some concensus on a spec in this group. developers who are focused on landing a patch dont want to wait that long. PTL's often have more time-sensitive things to deal with 21:33:10 i have already justified this chunk of my tuesday evenings to my wife, so there is some effort involved in rejustifying new timeslots ;) 21:33:38 sorry to jump bit off topic, just gotta get this out of my mind before I loose the point. x-project spec is really painful, how about moving it from single person effort to the stage where it's single person effort to convince TC that the _idea_ is worth of pursuing after which it would be driven by TC to wider community. Rather than that one person trying to convince all the big eevil oldtimers? 21:34:24 jokke_: so, smaller first test group? 21:34:35 jokke_: i don't think it's by necessity a single-person effort, but if you think the spec is a good idea then you may need to find other people to help. the tc can't unilaterally assign resources to help you implement it 21:34:57 fungi, thingee not saying *another* meeting for everything, but that a good idea spec gets a mini sprint to flesh it out and get it into a real spec shape 21:35:23 gets a mini sprint? anyone can book a sprint for themselves 21:35:26 jokke_: some tc members may sign on to help implement the spec, but that's not limited just to the tc 21:35:37 annegentle: not really, but rather insight from the folks who are supposed to be representing the technical community and could most probably tell already at the idea level if it will never get through or not 21:35:51 #link https://wiki.openstack.org/wiki/VirtualSprints 21:36:27 anteaya, yes, thanks! If the mini sprint were decided timewise in the cross project meeting, then maybe more interested people would turn up and get the spec in shape in that one meeting instead of over months 21:36:42 jokke_: "is this a good idea/is it likely to ever find enough backing to be implemented" strikes me as the reason why the tc votes on cross-project specs anyway 21:37:01 jokke_: so not really size as much as experience/instinct 21:37:10 maybe, but noone is standing in the way of anyone booking their own sprint, just sign up for the space 21:37:24 fungi: I'm not saying that TC has magical unlimited resources to pour, but one would have way easier path to bring stuff up to the wide audience if the TC is in general behind the idea and perhaps helping to form the first iteration of the spec to the form it has even chanse to get to the point in next weeks rather than months/cycles 21:37:25 for the amount of work that x-proj specs take to implement, we'd want something stronger than "maybe this is going to be implemented" 21:37:35 annegentle: exactly 21:37:39 jokke_: fungi: What I experienced with service catalog is that I couldn't implement it all and have to find people who can. 21:37:47 anteaya: Rockyg: I don't see any need for an official sprint, nor deciding on a time in this meeting. could just send an email to the list "hey I'm hacking on this spec at x time in #openstack-channel, interested parties welcome" 21:37:54 bknudson: yeah that makes sense 21:37:57 bknudson: +1 21:38:08 jroll: sprints aren't official that is my point 21:38:10 jokke_: I'd rather have it be an open group. Could be a TC workgroup, with TC members but opened to anyone interested 21:38:22 jroll: and yes the workflow you propose is my expectation 21:38:32 anteaya: yep +1 21:38:43 i think helping you get your spec into sufficient shape that it's implementable is part of why the tc is acting as the approving body for those specs 21:38:50 ok, well I encourage folks to respond to the thread. I think having specs with solutions and ready for feedback would be great. There's ideas for the product working group to help with that and get the relevant projects involved with a proposed spec. http://lists.openstack.org/pipermail/openstack-dev/2015-September/074867.html 21:38:53 ttx: I wondered about a TC workgroup stood up just for particular x-project efforts/specs 21:39:15 requiring a team dedicated to getting a x-proj spec makes sense to me -- you don't want the effort to fail just because one person lost interest 21:39:15 annegentle, ++ how do you recruit devs for a spec you need help designing/implementing to fit the openstack architecture? 21:39:22 annegentle: I tried to motivate TC members to form one for all the cycle. I can't drive them all 21:39:33 ttx: that would work 21:39:40 i'm unconvinced that waving a royal sceptre at a "working group" and making it official accomplishes much of anything 21:39:40 * thingee is not sure if he made his point 21:39:41 Rockyg: zactly 21:39:52 * thingee or made things worse 21:40:04 ttx: and yes, we'd have to pick and choose (strategically if you will) based on the availability 21:40:07 thingee: no not worse 21:40:08 thingee: i think people have simply ignored your call to move on 21:40:31 #topic open discussion 21:40:31 perhaps time to just use your #topic powers to force the issue ;) 21:40:37 oh shoot sorry thingee I didn't realize you closed it up 21:40:42 :) 21:40:47 fungi: I wish the meeting chair would have a magic wand to suddenly call all cats attention. I would use that 21:40:47 I would like to talk about next steps for spec : Return request id to caller 21:40:55 #link: https://review.openstack.org/#/c/156508 21:41:02 It got merged today. Thanks everyone again 21:41:03 ttx: its called kitty-treats 21:41:13 Should I reach to individual python-*client PTLs and request them to approve the blueprints? 21:41:34 lifeless, I have a cat who doesn't consider treats to be a treat 21:42:05 tpatil: would really recommend you start looking for liaisons for each project to be the point of contact. 21:42:10 Rockyg: more cowbell ? 21:42:13 ttx: that should be easy ... op the chair ... IRC has really powerful tools and channel flags to suppress noise ;) 21:42:27 thingee: Ok, got it. I will follow up with them then. 21:42:34 Thank you 21:42:36 tpatil: I don't think you should need per-project blueprints at this point 21:42:43 tpatil: you have a cross-project blueprint 21:42:50 yeah, we could get more aggressive with mode +/-v 21:43:01 lifeless: meh, blueprints are nice for tracking at release time though 21:43:01 tpatil: the whole point of this exercise has been building cross project consensus :) 21:43:03 but that seems a tad draconian at this scale of participation 21:43:11 lifeless, tpatil: might want per project for tracking purposes 21:43:12 fungi: ++ 21:43:12 lifeless: not to say it's the right thing to do, just sayin' 21:43:25 perhaps the liasion can file the BPs 21:43:30 for the respective project 21:43:32 jroll: I'll leave that to the projects 21:43:38 because it's just paperwork, no need for tpatil to do it all 21:43:39 jroll: its not a release notes thing in M though 21:43:46 jroll: exactly 21:43:46 Just placeholder bps, but when the are closed, you know another project is aligned 21:43:48 "the chair recognizes the gentlewoman in the blue nick" 21:43:56 lifeless: why wouldn't this be a release notes thing? 21:43:58 bps that link to the cross project spec. It's good for tracking in the individual projects. 21:44:04 jroll: because reno 21:44:11 reno? 21:44:17 jroll: I mean, blueprints are now decoupled from release notes 21:44:18 also playing with -v usually results in privmsg hell 21:44:25 thingee, ++ xactly 21:44:35 jroll: we put together an in-project-tree thing to do release notes 21:44:41 the blueprint just needs the link, that's it. simple 21:44:42 lifeless: well, how do you think folks compile release notes? :) 21:44:58 jroll: with reno, by writing the section when they propose the code 21:45:07 ooooooooooo 21:45:13 jroll: yeah, exactly 21:45:13 that's a fantastic idea I never thought of 21:45:17 somehow. 21:45:24 are/can we finally mova away from launchpad? :P 21:45:29 move 21:45:30 jroll: will be enabled on stable/liberty for now 21:45:33 I would like to bring something to people's attention and specifically on with what jokke_ mentioned and what I hear all the time from people involved in OpenStack in some way.. 21:45:42 Being able to keep up with the Dev ML... 21:45:58 so i know you all read the newsletter weekly and excited for it's distribution that you probably noticed the new section 21:46:00 http://www.openstack.org/blog/2015/09/openstack-community-weekly-newsletter-sept-12-18/ 21:46:03 jokke_: we're getting closer, but the last 10% requires 90% of the effort, or something like that 21:46:17 "What you need to know from the developer’s list" 21:46:29 fungi: I volunteer ironic to be a maniphest beta tester 21:46:49 #link http://www.openstack.org/blog/2015/09/openstack-community-weekly-newsletter-sept-12-18/ 21:46:51 I'm going to start writing bullet point only quick important info from the dev list 21:46:58 thingee: I will add bps under each project and start submitting code patches, also update whiteboard with crossproject spec approval 21:47:17 jroll, link from maniphest task/issue to crossproject spec would work instead of project bps 21:47:21 would love feedback on that first attempt...but I think if you read that, you'll be pretty much caught up from last week. 21:47:34 thingee: I like them a lot, but you already know that. 21:47:41 jroll: well, there's maniphest (or some other defect/lifecycle tracker), openstackid (authentication use cases) and also release artifacts (i'm starting work on improving that bit in the upcoming cycle) 21:47:43 jroll: this thread - http://lists.openstack.org/pipermail/openstack-dev/2015-August/072385.html 21:47:48 thingee: _this_ is why this hour is so valuable! ;) 21:47:50 thingee, I used them to update the prod_wg 21:47:58 Rockyg: indeed, reason number 3761429 I'd like to get on maniphest :D 21:48:15 fungi: yeah, just throwing my name out for when it's ready 21:48:17 you would also know that mordred really hates floating ips 21:48:21 thingee: so two topics for that 21:48:23 from reading it 21:48:32 thingee: the constraints stuff seems to be not widely enough socialised 21:48:36 yah 21:48:36 jroll: noted, ironic seems to like to live by the seat of its pants 21:48:38 jroll, Rockyg: so... the trick with Phabricator is that the component that does change tracking is not written yet 21:48:42 thingee: despite lots of emails trying to do Just THat 21:48:49 thingee: secondly the release notes thing 21:48:53 so we'd have to emulate that somehow 21:48:57 thingee: will be worth socialising 21:49:01 thingee: do I need to rant about them more? 21:49:03 lifeless: yep, I'm aware of the reno stuff, just never occurred to me to update while proposing code :) 21:49:29 mordred: get me a network 21:49:41 lifeless: constraints was already on my list. 21:49:47 :) 21:49:59 mordred: I think you need to find new topic for persistent rant unless you were allowed to order HP work laptop :P 21:50:18 mordred: we'll get you a spot on coffee talk and you can rant about floating ips there 21:50:21 jroll: you can track my adventures at https://wiki.openstack.org/wiki/Phabricator 21:50:24 fungi: awesome 21:50:38 thanks, ttx! 21:50:41 jokke_: but why would I stop ranting about these? people till seem to think they're a great default operational model 21:50:48 jokke_: :) 21:50:52 ttx: yep, I've started watching that :) 21:50:53 :D 21:51:24 mordred: I was more thinking of that it would be as good topic as any 21:51:34 ok anything else? 21:51:37 jokke_: AH! then yes, I'm with you 21:51:56 alriiiight! 21:51:58 #endmeeting