20:01:38 #startmeeting tc 20:01:39 Meeting started Tue Jun 2 20:01:38 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:39 ttx: \o/ 20:01:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:41 ttx: that's usually a reasonable guess 20:01:43 The meeting name has been set to 'tc' 20:01:47 o/ 20:01:47 * dims_ peeks 20:01:48 taking off as we speak 20:02:00 Our agenda for today: 20:02:00 o/ 20:02:04 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:15 #topic Add tc-approved-release tag for trademarkable projects 20:02:20 #link https://review.openstack.org/182474 20:02:28 We now have enough Yays to approve this one 20:02:35 Any last-minute comment/vote ? 20:03:04 * devananda lurks 20:03:12 Taking that as a no.. and approving 20:03:24 * morganfainberg is double secret lurking. 20:03:25 yay, glad that's sorted 20:03:34 indeed 20:03:38 * Rockyg shadows devananda 20:03:59 I'll be able to deprecate the "integrated-release" one now 20:04:05 yeah 20:04:07 #topic I18n team want to become an OpenStack Project Team 20:04:14 #link https://review.openstack.org/184920 20:04:18 This one should also be relatively painless 20:04:32 whoohoo i18n! 20:04:46 * flaper87 does the i18n dance 20:04:47 with the recent revotes we are above the required line 20:04:48 * dhellmann was surprised they weren't already an official team of some sort 20:04:48 and somehow this got on the board agenda for the next board meeting 20:04:58 really? 20:05:00 russellb: .... i18n? 20:05:12 atc status for their contributions 20:05:15 ... i have no idea ... 20:05:18 I'll give everyone a few more seconds to reapply previous votes if they want their vote properly recorded 20:05:23 but anyway, glad it's just sorted and i can report that. 20:05:33 so.. 30 seconds to ignition 20:05:38 ttx: let me vote, on slooooowwwww internet 20:05:53 * annegent_ says please 20:05:55 ok 20:05:56 you should upgrade for a european internet 20:05:57 oh, gotcha. Yeh, we probably want to figure out a tool that can count the contributions into the i18n tooling for atc instead of having to extra-atc them all 20:06:00 (also, when we move to zanata, hopefully around end of this cycle, that will be more automatable) 20:06:11 russellb: it would be good to have some documentation about how atc status will be granted to that team, yes 20:06:23 alright, approving now 20:07:05 dhellmann: once we moved from transifex to zanata, this should be easier to do... 20:07:06 did I mention I like the new vote-biut-let-everyone-express-opinion system ? 20:07:18 * flaper87 loves it too 20:07:22 +1 20:07:31 it's definitely clearer now 20:07:33 ttx: you didn't but yes I like it too! Thanks infra maintainers! 20:07:33 i wanted to ask what convention we should use with code review and tc vote 20:07:35 w00t 20:07:37 i've just used both, because why not 20:07:47 russellb: lol, same here 20:07:55 o/ 20:07:56 #topic Add compute kernel tag 20:08:02 #link https://review.openstack.org/180112 20:08:03 I went belt and suspenders and checked both 20:08:09 This one is likely to be a longer discussion, so let's timebox it to 20:35 UTC 20:08:19 Lively discussion on that review -- Most opposition to the tag is about it being useless, with some insisting it may be harmful 20:08:29 I'm still in favor of it -- The alternative being to let various documentation, websites and presentations present their own version of a "starting point" 20:08:31 now that the ops team has created a repo to define their own tags, I think we should let them own this one 20:08:40 and I think that would end up a lot more confusing to our new users than a clear answer 20:08:42 dhellmann: have a link to that? 20:08:50 http://git.openstack.org/cgit/stackforge/ops-tags-team/ 20:08:53 so I see some benefits and I don't see that many drawbacks 20:08:57 I did leave that in a comment on this review 20:09:04 so, I tried to summarize my point of view there about this being useful from a "start here" point earlier today 20:09:10 ttx: I'm not convinced the tags website is going to be the first place new users look 20:09:11 dhellmann: yeh, I just read your comment there 20:09:17 dhellmann: I'm fine with that, want to hear from jaypipes as well 20:09:18 ttx: yeah that happens already :) 20:09:24 I'm really failing to see how that tag will be useful. 20:09:26 zaneb: I'm convinced they wiull look into openstack.org/software first 20:09:26 i don't expect the tags website to be the first place people look either 20:09:35 I remain convinced that we need some product documentation, that this should be part of it, and that neither has anything to do with project governance. 20:09:36 zaneb: and that will exhibit tags in the near future 20:09:46 but i think it's useful for the TC to make some opinionated calls to say "yes, this is the official starting point" and expecting docs to follow that 20:09:47 If anything, it'll invite users to go and read tags instead of docs 20:09:55 which is something we've put lots of efforts on 20:10:02 zaneb: nice near-rant :) 20:10:20 dhellmann++ 20:10:27 russellb: yes, I like the idea of expressing that 20:10:38 dhellmann: ++ exactly my thoughts 20:10:49 I think dhellmann summed up my thoughts very well there. 20:10:52 right, so basically either the TC takes a stand on "start here" or we cede that to others and decide 20:11:05 dhellmann: I fear that we'll dilute the message 20:11:20 sdague: I think we cede that to others and encourage documentation for that specific purpose. 20:11:21 ttx: I trust our documentation team to get this right. 20:11:24 lifeless: I consider it a kind of success that you only described it as a 'near'-rant :) 20:11:33 jaypipes: ++ 20:11:38 any reasoning against a proposal like http://lists.openstack.org/pipermail/openstack-operators/2015-May/006886.html 20:11:39 dhellmann: and our marketing team for the website ? 20:11:42 zaneb: it was assertive but not angry. Thus not a rant. 20:11:50 I ask as docs person and tc person 20:11:54 ttx: I would expect them to consult the documentation, no? 20:12:06 and of course docs are the hardest part of this :) 20:12:10 dhellmann: I wouldn't bet any money on that 20:12:24 ttx: but we should encourage that behavior 20:12:32 ttx: you have more experience with them than I do, so maybe I'm overly optimistic 20:12:32 dhellmann: and when there then becomes a fight with the docs team because there are different opinions on "start here"? 20:12:34 instead of encouraging users to read tags 20:12:38 annegent_: I'm embarrassed to say I had not seen that post yet. :( 20:12:41 dhellmann: at least by making them piggy-back on the tags (which the website will exhibit anyway) we could make sure the message would be clear 20:12:50 sdague: the docs team can have more than one "start here" for different purposes, can't they? 20:12:50 so much of OpenStack becomes word-of-mouth it seems. More objective measures are welcome, from any one. 20:12:56 jaypipes: ah it happens :) 20:13:16 sdague: we are already dealing with that with debian install guide 20:13:18 which doesn't package nova-network 20:13:18 dhellmann: sure, which works fine for someone that already knows openstack 20:13:22 so... 20:13:27 zaneb: so, at the risk of repeating stuff; what are your proposed alternative solutions that you reference in the review ? 20:13:38 I was in the Ops tags session at the summit, and I think it's good to get multiple viewpoitns 20:13:48 I'd also like us to consider the bitergia offer 20:13:53 lifeless: read a couple of comments back 20:14:02 * flaper87 needs to read bitergia's email 20:14:15 sdague: I think it can be clearly explained how to install different projects for different goals without the governing body trying to pick one true way to do an installation. 20:14:16 I still firmly think that OpenStack as a community is better served by a single door that's easy to draw people in, and then expand into the rest of the OpenStack universe 20:14:25 lifeless: but basically, more user survey data; case studies on SuperUser 20:14:26 sdague: ++ 20:14:42 sdague: ++ 20:14:43 and even for the docs writers, of which there are a handful, we have to still figure out what to write/include through consultation and word-of-mouth 20:14:44 sdague: but what if that door takes me where I don't want to go ? 20:14:44 sdague: I do as well. But I don't think a single tag like kernel:compute does that. 20:14:44 sdague: that is what the marketing teaml asked me, too 20:14:49 * annegent_ taps mic 20:14:55 * dhellmann listens to annegent_ 20:14:55 that's one of my main issues with the tag 20:14:57 flaper87: then don't go there 20:15:12 sdague: why isn't there a second door ? 20:15:16 the point is that anyone experienced enough to skip past it can 20:15:23 sdague: ++ 20:15:24 sdague: so why is no distro doing that? 20:15:27 anteaya: SHOUT ? 20:15:30 bah 20:15:32 annegent_: SHOUT? 20:15:36 dhellmann: all we've come up with so far is: current install guide living in openstack-manuals, followed by a "gathered across repos" install guide 20:15:38 dhellmann: if a part of OpenStack is optional, then isn't it not kernel by definition? 20:15:39 because if you have a building with 10 doors, people that have never been in before get confused and leave 20:15:46 it's my slowwwww internet 20:15:47 :) 20:15:48 flaper87: requiring newcomers to read a 50-page doc to determine where to start... 20:15:54 it's great for people that already know the building 20:16:10 At least before we were exposing them to the "nova/swift/neutron" trilogy 20:16:10 there are plenty of opinionated installers 20:16:12 ttx: can those docs be improved to have a "start here" section? 20:16:24 I'm now thoroughly confused 20:16:29 here's my understanding 20:16:34 annegent_: I see quite a few people in this meeting who would like to provide much more detailed guidance on that issue. I just don't think that the governing body needs to be doing it, because this tag isn't going to be used to set any governance policies. 20:16:38 flaper87: we do that already with three opinionated architectures 20:16:42 flaper87: if we can't give a "start here", how would the doc team be able to answer that concisely ? 20:16:49 the operators - folk who have already deployed - at the ops meetup, said they wanted a clear articulation of the onramp to becoming operators? 20:16:51 annegent_: ++ 20:16:54 ^ is that a true statement ? 20:17:06 lifeless: yes 20:17:11 lifeless: yes, it was expressed in Philly that way 20:17:13 lifeless: yes 20:17:15 lifeless: yes 20:17:21 so did the board at the board meeting 20:17:21 lifeless: it's basically the only tag we worked on so far that they feel has some value to them 20:17:28 ttx: because if the doc team does it, that doesn't reflect an opinion being expressed by the TC, and so it's less contentious -- the doc team isn't saying anything that could be construed as "your project is not important" which is the issue we keep having with this tag 20:17:34 lifeless: is that something ops-tags can help with ? 20:17:37 ttx: but we're working on the tag because they said they need an onramp 20:17:44 dhellmann: right 20:17:46 ttx: right? 20:17:58 dhellmann: one reason I think it needs to be about technical requirements and not subjective 20:18:19 lifeless: yes. They said the hardest thing was to get a clear, limited set of projects to consider when they first open the openstack door 20:18:31 if it takes more than one minute to find out where to start, we fail 20:18:32 i don't see why this would be punted to ops, "here, try this" is something we owe them, not the other way 20:18:43 lifeless: actually it was proposed several times already. The reason keeps changing, but that was the latest ;) 20:18:48 ttx: So, *how* does the tag provide the onramp? It itself isn't prose, nor intrinsically discoverable, and like code comments could easily become skewed. 20:19:13 the tag itself doesn't, it's an official designation that i would expect other things (docs, website, whatever) to be based on 20:19:18 lifeless: I see it more as an index than the actual map 20:19:28 where I'm going with this is - 20:19:36 lifeless: it is intrinsically discoverable if the openstack.org/.software website is redesigned to exhibit it by default and let you navigate tags to discover other projects in the same interface 20:19:38 right, we can't get the information to flow out from "start here" until we actually decide what it is 20:19:40 if we want to ensure that there *is* a minimal set of things; that is governance. 20:19:46 "my manager told me that our company needs an openstack... what things do i need to install to not get fired?" 20:19:50 E.g. saying to Nova - you must be deployable without cinder and without Neutron 20:19:51 russellb: I don't think the docs team needs us to hold their hand on this. Would we do anything like this for a nova spec? 20:20:08 fungi: what minimal set of things 20:20:12 it's not hand holding 20:20:14 ttx: exactly 20:20:14 dhellmann: russellb: I think an official tag helps the docs team 20:20:19 it's clearly controversial, and we're the right group to make a call 20:20:30 it provides focus and prioritization, is that wrong? 20:20:40 right, punting to someone else is not always the right answer 20:20:54 annegent_: not at all 20:20:56 annegent_: some people think focus is wrong, yes. 20:21:00 annegent_: I don't 20:21:00 right, it seems like not making a call because it's controversial just means we're setting up some other team to get everyone to hate them when they do the "wrong" thing as considered by some segment of the community 20:21:12 no, that's not what I'm saying 20:21:28 sdague: or just that it continues to be painfully confusing because no 2 sources agree 20:21:40 it's controversial because there are many possible useful answers, and we're picking only one based on a limited view 20:21:41 ttx: heh 20:21:42 zaneb: is it the prioritization that's hurtful? 20:21:42 russellb: heh, might be that 20:21:43 I guess we should probably back off to two questions. #1 should the TC have an opinion on "start here" 20:21:52 #2 if so, what is it 20:22:06 #1 yes -- if we can't who else can. 20:22:07 annegent_: kind of 20:22:09 on question #1, yes, i think that's a very useful technical community deliverable 20:22:12 so there are two things I think; 1a) For Nova, how can we make sure there is a minimal set - that X and Y and Z don't creep in, and 1b) should we be saying that; and 2) Is nova the right/only project to be providing that guidance for, or are there many such projects? 20:22:27 and also agree that no other group is better positioned to decide what that is 20:22:38 I think it's pretty clear that a "start here" definition should include the fewest number of projects based on the use case of "how do I not get fired while testing openstack" but that may not actually be a useful starting point for someone else 20:22:41 who disagrees with #1 above 20:22:50 zaneb: ok, fair 20:22:52 so I think I'm agreeing with sdague here - framed slightly differently 20:22:54 dhellmann: I think that's why use cases are more helpful 20:23:03 and avoiding "kernel" nomenclature 20:23:12 annegent_: seed ? 20:23:16 dhellmann: that's fine, because it's not like we're going to go yell at people that start somewhere else, this is about "I don't know where to start" folks 20:23:17 annegent_: right, and that's why I think using words in prose instead of tags is the way to solve the original problem posed by the ops community 20:23:34 and we may have a few starting points for clear use cases 20:23:36 that's fine with me 20:23:37 dummies-start-here 20:23:37 dhellmann: / fungi: the issue I have with 'fired while testing openstack' is that that is so damn amorphous. We've opted out of being a product. 20:23:45 ttx: I hate to say it but I do not think the TC should have an opinion on "start here". 20:23:47 I'd agree with #1 if we also agree on adding other starting points 20:23:48 there, I said it. 20:23:50 but the compute (VM) focused one seems like the most obvious start 20:23:55 ttx: kernel has too much meaning in linux, gets confusing 20:24:00 jaypipes: I know you don't, and I disagree with you on that 20:24:05 is it VM's? Is it Containers? Is it storage? 20:24:09 I don't think it's a start here though. I think it's use cases. "If this is your goal start here" 20:24:10 jaypipes: but that is fine. That's why we do vote 20:24:13 flaper87: the other obvious choices are single-sproject sets 20:24:16 jaypipes++ 20:24:17 annegent_: Yes! 20:24:17 lifeless: based on the user survey, yes, it clearly is 20:24:31 lifeless: i don't disagree. just trying to put myself in the place of the ops community members who have requested a grocery list of "what is an openstack" 20:24:38 jaypipes: the distro's wont have that opinion. service providers wont. woulud you advocate that no one fills that need, then? 20:24:38 jaypipes: if the TC can't have an opinion on that, I don't see who else can 20:24:39 that's where most people are starting 20:24:44 dtroyer: if we don't count keystone, many of them are single project sets. 20:24:50 annegent_: yes, that would be much more useful imho 20:24:51 ttx: ++ 20:24:52 devananda: distros very much have opinions 20:24:52 ttx: exactly 20:24:54 devananda: the distros absolutely have that opinion. 20:25:07 ttx: distros 20:25:08 lifeless: oh yes, but not on where to start 20:25:13 devananda: Ubuntu for instance has a very specific and particular process for moving something from 'its out there' to 'supported' 20:25:19 jaypipes, zaneb; and it's fine. Our start-here is pretty minimal 20:25:34 lifeless: supported by distro X is not the same as "start here" 20:25:39 not even remotely 20:25:45 sure 20:25:45 http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014 - project usage 20:25:48 there was a disconnect 20:25:55 so here's the thing.. defcore has essentially defined a starting point 20:25:56 timecheck - 10 min left 20:26:12 markmcclain: an absolutely bare minimum least common denominator starting point 20:26:21 for now 20:26:26 we should *not* be using that as our standard, IMO 20:26:27 defcore is set to grow though 20:26:32 markmcclain: they really haven't, they've taking capabilities 20:26:37 I guess I'm stumped by the singularity of the "start here" argument. Nobody I know asks "how do I start?". They instead ask "how do I accomplish X with a minimal set of things." 20:26:39 for instance, there is no networking specified 20:26:50 russellb: I thought that's exactly what people were calling for here? 20:26:51 jaypipes: ++ 20:26:55 jaypipes: I guess we're talking to different people 20:26:57 jaypipes: exactly 20:27:09 jaypipes++ 20:27:16 back to sdague's first question -- quick show of TC hands on question #1: should the TC have an opinion on "start here" 20:27:16 because I talk to a bunch of people that aren't doing OpenStack because there is no start here 20:27:16 let's please not confuse defcore with this 20:27:18 and that "how do I accomplish X with a minimal set of things" is best answered, IMHO, by documentation. 20:27:23 but I get the feeling that managers who ask folks to stand up "openstack" are going to think of the capabilities covered by defcore 20:27:29 #1 -- yes, because if not us, who else can 20:27:30 ttx: #vote ? 20:27:39 I think its reasonable and useful and can meet the operator needs to document 'this is the onramp for VM's in OpenStack today': Nova+X+Y etc 20:27:41 russellb: ok, ok 20:27:49 sdague: are people who just want to get on the hype wagon for no reason our target audience? 20:28:01 #startvote should the TC have an opinion on "start here" ? yes, no, meh 20:28:02 Begin voting on: should the TC have an opinion on "start here" ? Valid vote options are yes, no, meh. 20:28:04 Vote using '#vote OPTION'. Only your last vote counts. 20:28:06 #vote yes 20:28:08 #vote yes 20:28:09 zaneb: no, they are smaller institutions like colleges 20:28:10 zaneb: that's not what sdague is saying, you know that. 20:28:10 I think #1 is kindof misframed 20:28:12 #vote yes 20:28:14 #vote no 20:28:19 #vote no 20:28:22 #vote yes 20:28:24 #vote no 20:28:27 I'd vote yes for a different #1 20:28:30 lifeless: how would you better frame it ? 20:28:33 lifeless: same here 20:28:33 #vote no 20:28:34 #vote yes 20:28:35 #vote no 20:28:57 I'd vote yes for "start here for this use case" 20:28:58 flaper87: same question 20:29:05 annegent_: that's my interpretation ... 20:29:09 russellb: ah ok 20:29:10 that's why it's called "compute" 20:29:24 #vote yes 20:29:24 ttx: 'should the TC have an opinion on start here for this use case today' 20:29:25 and not just "openstack" 20:29:31 I'd vote yes for "The TC members should absolutely contribute their opinions to documentation that details how to start accomplishing X use cases" 20:29:34 that's what the tag proposes! 20:29:43 lifeless: that is what the question is. 20:29:45 jaypipes: :) 20:29:46 russellb: is the idea to add more tags for other starting points ? 20:29:48 you can fix your vote :) 20:29:53 sure 20:30:02 #endvote 20:30:03 Voted on "should the TC have an opinion on "start here" ?" Results are 20:30:04 yes (6): annegent_, ttx, russellb, jeblair, sdague, dtroyer 20:30:05 this is the first one, for "compute" 20:30:06 no (5): lifeless, dhellmann, jaypipes, markmcclain, flaper87 20:30:10 Let me reframe the question 20:30:20 ttx: two specific things there: binding it to use cases, and making clear its retrospective not prospective. 20:30:30 #startvote should the TC have an opinion on start here for this use case today? yes, no, meh 20:30:31 Begin voting on: should the TC have an opinion on start here for this use case today? Valid vote options are yes, no, meh. 20:30:33 Vote using '#vote OPTION'. Only your last vote counts. 20:30:35 #vote yes 20:30:35 #vote yes 20:30:38 I think we *can* do a prospective one, but its a whole different discussion - and not what the operators asked for as I understand it 20:30:39 #vote yes 20:30:41 #vote yes 20:30:47 #vote meh 20:30:52 #vote yes 20:30:52 #vote yes 20:30:54 #vote yes 20:30:54 jeblair: :) 20:31:00 #vote yes 20:31:01 (i just wanted to vote meh once in my life) 20:31:46 markmcclain, dhellmann, jaypipes ? 20:31:55 I guess "meh" is abstain? 20:31:59 #vote meh 20:31:59 dhellmann: yes 20:32:20 ttx: is this opinion == a tag? 20:32:29 jaypipes: nope 20:32:33 that's a different vote 20:32:42 jaypipes: next question 20:32:44 #vote yes 20:32:59 markmcclain: ? 20:33:09 #vote meh 20:33:23 #endvote 20:33:24 Voted on "should the TC have an opinion on start here for this use case today?" Results are 20:33:25 yes (9): annegent_, ttx, russellb, jaypipes, jeblair, sdague, lifeless, dtroyer, flaper87 20:33:26 meh (2): dhellmann, markmcclain 20:33:28 #2 if so, what is it 20:34:05 and, more importantly, how do we get to some rough agreement there 20:34:14 if the TC has an opinion, i'd like to see it documented in an official way 20:34:20 What are the options on the table for the TC to express that opinion 20:34:22 and not just "go participate in every possible place that the opinion may have an impact" 20:34:29 I would like to see a list with more than one use case proposed. 20:34:29 Tags have been built for us to express that 20:34:30 yeh, I guess 2 is really 2 questions 20:34:37 dhellmann: ++ 20:34:41 how do we express and opinion, and what is it 20:34:44 the tags were conceived as a reflection of project attributes, if the tags here simply state required relationships, I believe that's a start for what we are looking for 20:34:55 and build from there 20:35:14 looks like we're hitting our time box ... 20:35:18 dtroyer: that might also be a more constructive approach 20:35:21 So of those who voted yes -- how would you express that opinion ? 20:35:25 quick ;) 20:35:29 tags were meant to be objective, not subjective. 20:35:31 ttx: ^^^ 20:35:32 - tags 20:35:44 so, it's not a compute kernel, you're really saying whaat's the minimum I need to stand up a compute cloud 20:35:44 I'd like the ops team and bitergia to tackle 20:35:46 i think a tag seems like a fine way to do it. 20:35:47 some other doc ? 20:35:53 jaypipes: exactly. "nova reuiqres glance" is an objective statement 20:35:57 documentation can be opinionated and subjective, which is why I think it's good to have TC members submit their opinions to documentation. 20:36:03 dtroyer: ++ 20:36:03 i also disagree that we have to be objective about everything 20:36:09 jaypipes: "the minimal set of project s to deliver basic compute stuff" happens to be prettu objective 20:36:18 The TC feels a lot less useful to me if we're limited to only being objective 20:36:21 tags 20:36:23 russellb: true, but we'll get somewhere faster if we start with that 20:36:24 ttx: apparently that isn't so objective :) 20:36:24 russellb: ++ 20:36:26 and yes we are hitting the timebox 20:36:26 russellb: ++ 20:36:29 ttx: until mordred wanted DNS :) 20:36:34 russellb: I actually agree with that fwiw 20:36:34 timebox! 20:36:46 sdague: any last-minute question to help you make progress ? 20:37:25 don't take it personally? :) 20:37:27 honestly, I don't know 20:37:30 russellb: but on technical questions, not political questions 20:37:40 this is technical IMO 20:37:52 I respectfully disagree 20:37:53 zaneb: I fail to see how telling people which are the basic set of projects you need to run Nova is political 20:37:54 ok 20:38:06 this seems pretty basic 20:38:06 zaneb: yeah that's one part of your argument I don't get... yet. 20:38:13 ok, let's clariufy off-meeting 20:38:18 sounds good 20:38:20 #topic Adding distribution packaging to OpenStack 20:38:28 #link https://review.openstack.org/185187 20:38:33 ttx: that isn't the question though. as dtroyer pointed out, the answer there is completely objective 20:38:34 * russellb takes a deep breath 20:38:40 This one sounds like a good idea, the opposition is mostly about how early it is 20:38:46 yeah, +1 to the idea 20:38:49 The team is just getting created, doesn't even have a PTL or a clear plan yet 20:38:52 * flaper87 sips his wine 20:38:59 Personally I like to bless existing teams, not the idea of a team, maybe that's just me 20:38:59 personally would like it to be a little bit more baked of a proposal 20:39:02 * flaper87 likes the idea 20:39:03 no suse? 20:39:05 this patch doesn't block getting work done 20:39:09 i.e. "Are you OpenStack" rather than "Will you be OpenStack" 20:39:20 ttx: why don't we make the tags something like "depends-on:keystone" and "can-use:neutron" then, instead of the current situation which is everyone's opinion on what is "minimal" for a particular use case?' 20:39:25 I think it's great the patch is there and that some opinions where already laid out 20:39:27 no PTL, no clear idea of how the different distros will collaborate in a single team 20:39:34 yah 20:39:39 so there are two routes forward 20:39:43 so, I think the team thinks it is blocking getting a gerrit repo up 20:39:43 that'll help interested folks to get started 20:39:49 russellb: well, some people said it would be great to let them create repos under openstack/ to avoid renaming 20:39:49 build the team up more; stuff on stackforge; revisit later. 20:39:51 or 20:39:59 make this the debian-only-thingy team 20:40:06 i think there's a third option 20:40:15 russellb: those are the reasons I proposed using stackforge 20:40:17 annegent_: my colleagues at SUSE are interested, not sure why they didn't mail ;( 20:40:18 I'm fine letting them create under openstack/* if that's all it takes 20:40:20 and if we can figure out how to get them a gerrit repo up, I think that would be good 20:40:24 which is for the folks who are involved to continue working out a plan on the mailing list 20:40:29 AJaeger: ah ok 20:40:37 jeblair: ++ 20:40:38 and then approve them as an openstack project 20:40:39 jeblair: yeah, i didn't expect that to take long 20:40:43 that's my preference 20:40:43 jeblair: I see that as basically route 1, but sure 20:40:55 jeblair: +1 20:40:58 jeblair: are they blocked on having a git repo in the mean time? 20:41:06 because I'd hate to have another magnum stall where they effectively blocked moving forward for 4 months on a chicken vs. egg problem with getting a repo 20:41:09 or are we not even at a stage where they know what sort of repo(s) they want? 20:41:09 ok, so just WIP the proposal since it's at the very minimum 2 weeks too early 20:41:10 jeblair: all I'm saying is that they can get stuff on stackforge anytime they need, they don't need to stall 20:41:15 can they start somewhere else while the plan is sorted out? 20:41:16 it seriously should not take long to write a simple plan in text form 20:41:17 renaming isn't that hard 20:41:24 russellb: ++ 20:41:25 russellb: exactly 20:41:25 annegent_: I consider it too early, there need to be more discussions... 20:41:26 that people agree to as "this is what we're doing and how we're collaborating" 20:41:27 russellb: ++ 20:41:29 lifeless: it's SUPER hard 20:41:30 I would like to see evidence of them working together, personally from experience with the install guide. 20:41:32 and I'm not really seeing them 20:41:36 if they don't hvae that, i don't see a git repo as valuable or useful 20:41:38 annegent_: +1 20:41:42 i really don't want to rename 100 repos 20:41:44 jeblair: I stand corrected. InfraAAS has spoken 20:41:50 which should be able to start out in openstack 20:41:56 jeblair: aww man yah 20:42:05 jeblair: 100 repos?! wtf that worries me more than anything :) 20:42:11 annegent_: right, i'm also concerned that this makes no sense as a single team, and reality is that it's 2 or 3 teams 20:42:17 (and i also have a general issue with encoding software development lifecycle attributes in git repository names) 20:42:22 would like some comments on that from people doing the work 20:42:33 ok, so do we agree to delay it until the plan is more baked ? 20:42:37 lifeless: repo per package 20:42:40 russellb: I'd expect the plan to show how the collaboration will happen 20:42:40 presumably 20:42:49 no point in discussing it further today then 20:42:52 it's not clear how distro specifics are done IMHO - whether there's one Debian, one Ubuntu, etc repo, or one RPM or one DEB - or all in one... 20:42:54 russellb: yeah 20:43:00 so, it's also fine if we think this is just a debian effort and call it openstack/deb-packaging 20:43:15 overall, I love the idea 20:43:19 because maybe this is like the puppet / chef / ansible thing 20:43:20 sdague: that's what I want them to sort out 20:43:28 sdague: yeah, i think that would be fine if that's what folks want to do 20:43:28 sdague: that's my expectation, personally 20:43:30 sdague: exactly 20:43:34 sdague: horiizontal "packaging" or moree like puppet/chef 20:43:50 it sounded though like there was some cross distro buy in from the list and discussion at summit 20:43:56 OK, Let's just WIP the proposal and come back to it when it's matured a bit ? 20:44:00 maybe my reading is incorrect 20:44:02 only with the really high level idea of "use infra to build packages" 20:44:06 ttx: +1 20:44:07 the summit issue is that you get a very small set of folk in a room 20:44:09 often 20:44:10 since we have other topic to cover 20:44:13 because conflicts 20:44:16 i expect the actual collaboration to be base infra stuff 20:44:19 sdague: that was my impression from the current discussion, too 20:44:29 ok, so we should at least give zigo some specific "do this next" 20:44:35 +1 20:44:53 sdague: the cross distro buy in depends on the details 20:44:54 sdague: yeah he'll want that 20:45:06 #agreed Packaging team proposal should be WIPed until the plan is more baked 20:45:16 #info we should give zigo some specific "do this next" 20:45:20 1) work out whether it's 1 or more horizonatl efforts 20:45:21 so I guess that's "please get a more concrete plan of what contents are in the repo, and what the plan is foir what's in that" 20:45:23 2) describe the collaboration plan 20:45:24 isn't reference/new-projects-requirements.rst the key thing? 20:45:27 jeblair: ++ 20:45:29 I mean, thats our benchmark 20:45:34 jeblair: do I hear you taking an action hgere , 20:45:40 here? 20:45:59 can do, will incorporate what i and sdague said 20:46:02 #action jeblair to give zigo some specific "do this next" 20:46:05 and anything else anyone spits out 20:46:07 #topic Ironic is considering changing their release cycle 20:46:13 cool, thanks jeblair 20:46:14 #link https://review.openstack.org/185203 20:46:18 I think the plan jeblair wants is infra-level, not governance and we should just +1 the project 20:46:40 This is more of a heads-up -- we have a thread about it started at: 20:46:44 #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/065036.html 20:46:48 lifeless: (which use of 'infra' was that?) 20:46:48 o/ 20:46:53 FWIW this was discussed with the release team and we agree to use Ironic as an experiment in this direction 20:46:59 jeblair: the infra team 20:47:02 Ironic doing it is not that much of an issue, but it has interesting side-effects 20:47:03 devananda: great write up, btw! 20:47:08 * russellb happy if release team is happy 20:47:12 Basically we need to relax the constraints on "common versioning" (having "liberty" things be a set of diverse version numbers)... 20:47:12 flaper87: ty 20:47:13 lifeless: no, we're not involved; i think this would be a new openstack project 20:47:17 Yay ironic! 20:47:18 ... and also overhaul the stable point release process (since we won't be able to tag a common point release anymore) 20:47:23 jeblair: in that your needs around repo counts, locations etc are not governance concerns AFAICT. 20:47:25 Discussion on release versioning @ 20:47:25 I'm happy to see projects experimenting with this 20:47:27 #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/065211.html 20:47:32 and Stable point release abandonment / process overhaul discussed @ 20:47:35 fwiw, I've just been told that morganfainberg has fielded several questions on when/whether keystone will follow suit 20:47:35 #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html 20:47:47 so this is already starting the conversation in other projects 20:47:49 So please chime in on those threads if you have a strong opinion either way 20:47:51 I will confirm what devananda said. 20:48:28 devananda, morganfainberg : I think a lot of projects are going to find this easier to manage, but it would be good for us to experiment with one or two this cycle to work out the kinks in the process changes 20:48:30 lifeless: (I still think a project team that doesn't even have a team or a lead yet is not "baked enough" for us to make a final call 20:48:31 ) 20:48:43 I would have expected any project that is reasonably usable "stand-alone" to be interested... 20:48:45 ttx: sure, so that should be the thing :) 20:49:04 but the impact on developers that this seems to offer (and really, is the impetus behind the proposal) seems to be more interesting 20:49:17 devananda: I suspect even some of the others will find it appealing 20:49:30 dhellmann: agreed re: try it in a few projects first 20:49:34 Still a lot of details to clear on the above-mentioned "side-effects" 20:49:48 so i would not rush anyone else in that 20:49:55 dhellmann: keystone will not be moving immediately. I worry about disrupting too much. Even though I like the release model proposed by ironic better personally. 20:50:00 ironic has been the forerunner on trying new things, and our developers seem comfortable (and some are clearly eager) to try this out htis cycle 20:50:14 I'm just happy folk want to reduce our cycle time:) 20:50:19 anyway, that was more a heads-up than a full-fledged discussion. Please go to the threads if you have something to contribute 20:50:20 we'll get down to daily at some point 20:50:21 yeh, lifeless's requirements management plan will definitely need to get fully implemented, because the coinstallability is going to be one of the key questions I think 20:50:31 dhellmann: i'll be looking to you & ttx for some guidance on _how_ to do it, as I'm not as experienced at release mgmt as either of you 20:50:40 #topic Move application to current projects up in tag page 20:50:41 ironic is definitely a good experimental starting point 20:50:47 #link https://review.openstack.org/184576 20:50:51 Added this one to the agenda so that we can bypass jeblair's -1 20:50:59 jeblair: Basically the tagged-projects directive reads data from projects.yaml so there is no duplication. 20:51:10 devananda: we'll figure it out together :-) 20:51:11 so if you remove your -1 I'll proceed in approving 20:51:51 #topic Workgroup reports 20:52:02 ttx: i will read the comments and attempt to understand them 20:52:23 jeblair: let us know if you still don't get it, we should have 2 min in Open discussion 20:52:26 On the project team guide WG, we worked on setting up the repository 20:52:31 And announced the virtual sprint 20:52:38 I'll probably use some of my travel time next week to start writing stuff there 20:52:47 annegent_, flaper87: News on the communications WG ? 20:53:10 got a blog post out last week 20:53:14 #link https://wiki.openstack.org/wiki/VirtualSprints#OpenStack_Project_Team_Guide 20:53:15 post-summit wrap up 20:53:37 annegent_: should we set up some opt-in proofreading? 20:54:02 ttx: srsly I'd love help 20:54:12 that'd be great, indeed. 20:54:20 * russellb happy to help 20:54:20 annegent_: maybe post the draft of the text on openstack-tc ? 20:54:27 or some etherpad ? 20:54:27 #link http://www.openstack.org/blog/2015/05/technical-committee-highlights-may-29-2015/ 20:54:29 russellb: we'll poke you :D 20:54:39 ttx: we keep it on an etherpad 20:54:51 I still don't completely know if we're covering what we should, does anyone have feedback they've heard? 20:54:54 maybe a reusable etherpad url then 20:55:07 annegent_: I think it covered what it needed to cover 20:55:08 ttx: yup, we have that. lemme get it 20:55:15 Tags: TC 20:55:18 the compute kernel tag ting 20:55:18 #link https://etherpad.openstack.org/p/next-tc-blog-post 20:55:20 i got a chuckle out of that 20:55:26 thats a thing I think we should get more engagement on 20:55:28 lifeless, markmcclain, jaypipes: you suggested an "architecture" WG, is it something you could set up ? 20:55:30 and here we keep a list of topics to write on 20:55:32 #link https://etherpad.openstack.org/p/tc-communications-topics 20:55:45 annegent_: the problem I had was the folks who were unhappy didn't communicate that until campaign time 20:55:48 lifeless, markmcclain, jaypipes: I called it the "Scuba WG" since I picture it deep-diving into projects, discovering issues and helping fix those 20:55:53 we could merge those 2 etherpads 20:55:57 annegent_: so no I haven't heard anything 20:56:04 flaper87: single etherpad ++ 20:56:04 ttx: hah, sure. 20:56:22 lifeless: clarifying the mission of the WG would be great for a start 20:56:25 ttx: unfortunately, my bandwidth won't allow me to really play a lead part in that one. 20:56:27 russellb: roger, I think we can drop the later then 20:56:30 annegent_: ^ ? 20:56:46 ttx: I have some early stage thoughts here - https://wiki.openstack.org/wiki/Lifeless/ArchitectureThoughts - haven't started on a WG per se yet 20:56:46 i hope everyone acts as a scuba anyway 20:57:00 ttx: sure.. can collaborate with lifeless 20:57:04 seems most people here are deep diving into one area or another 20:57:17 interested in what the WG proposes though 20:57:20 russellb: I'm tired of acting as scuba and getting no recognition for it 20:57:21 lifeless, markmcclain: ok, let's have something to elaborate on for next week 20:57:25 #topic Open discussion 20:57:35 I'm good with etherpad drafts! 20:57:36 Looks like mordred is late in kicking off the M naming process (was supposed to start yesterday) 20:57:44 anteaya: not sure what recognition needs to be different than every other openstack contributor? 20:57:49 ttx: i think he did though? 20:57:53 jeblair: maybe you could subst, or we'll just move the dates off 20:57:54 anteaya: good input anyway 20:57:55 russellb: okay 20:58:01 jeblair: oh, recently ? 20:58:02 cool 20:58:05 ttx: yeah, today 20:58:05 annegent_: I'll let you know if I hear anything 20:58:06 Got contacted by the Japanese community which wanted to help suggest names, which is great news 20:58:16 #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/065515.html 20:58:18 In other news, we've been setting up a chair rotation on the cross-project meeting (Tuesdays at 21:00 UTC). 20:58:22 #link https://wiki.openstack.org/wiki/Release_Naming/M_Proposals 20:58:30 I think it's essential so that we all experience the current system and come up with ways to improve it. 20:58:38 I did last week, Doug is doing this week. Who wants next week ? 20:58:58 flaper87: do you have bandwidth to write this week's post? Or do we punt to next week? 20:59:02 ttx I can take a turn next week 20:59:10 markmcclain: cool, thx! 20:59:12 (and there are already a lot of really good M names suggested, with nice explanations) 20:59:29 I'll add a chair rotation paragraph on https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting 20:59:30 annegent_: I can do it, I think we can decide depending on the topics we have 20:59:34 so people can add themselves 20:59:38 i saw MURICA proposed on twitter, as a follow up to liberty (which i don't think should be included, but i chuckled) 20:59:42 but if there are enough, I'll give it a go 20:59:42 (and some hilariously bad ones) 20:59:56 #action ttx to document chair rotation schedule on https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting 21:00:07 someone has added MURICA to the wiki, yes 21:00:11 oh dear 21:00:25 flaper87: the kernel discussion is a good deep dive 21:00:29 so... the TC gets to cull a bit right? 21:00:29 it's safely in a special 'not meeting criteria' section 21:00:31 Japanese comlmunity suggested "Musashi" which is an old name of Tokyo AND aJapanese sword master 21:00:40 safely in the "ignore these suggestions" section 21:00:43 ttx: yep, is on there 21:00:57 "noted, and duly ignored" list 21:01:00 excellent 21:01:08 sdague: no culling, but the tc would have to act to add murica since it doesn't meet criteria 21:01:15 jeblair: ok 21:01:19 that's good enough for me 21:01:22 Alright, time to end 21:01:26 Thx everyone 21:01:29 o/ 21:01:30 #endmeeting