20:01:31 #startmeeting tc 20:01:32 Meeting started Tue Jul 21 20:01:31 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:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:35 The meeting name has been set to 'tc' 20:01:40 OK... here is our agenda for today: 20:01:48 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:53 lifeless is here in room as well, it's break in nova meetup, he'll get to a keyboard 20:02:00 #topic Add the "OpenStack UX" Project 20:02:06 #link https://review.openstack.org/199768 20:02:13 Looks like this one is pretty close now, still missing a couple approvals 20:02:21 * ttx checks current state 20:02:44 and bites at that chicken skewer at the same time 20:02:56 yeah, still a few short 20:03:00 Any last-minute question ? 20:03:09 doubt ? uncertainty ? 20:03:56 I think it's worth a try now that it doesn't have a confusing name 20:04:07 still missing >=1 20:04:37 if no question and novote, let's postpone it 20:04:48 ah, 7 now 20:04:59 if no more question I'll approve it now 20:05:35 ... is silence a yes ? 20:05:41 ++ 20:05:50 ++ 20:05:52 o/ 20:05:53 yes :) 20:06:03 this group seems pretty happy to express disagreement, i wouldn't worry about that! 20:06:07 alright, let's see if this can merge with curent state of repo 20:06:09 silence == passive agreement 20:06:19 #topic Add Stackforge Retirement resolution 20:06:26 #link https://review.openstack.org/192016 20:06:32 We had good discussion and progress on this one. I posted my last concern as a comment earlier today. 20:06:42 It's about ripping out the "stackforge" name and the confusion it may cause in our wider community 20:06:52 On one hand it's true that since the requirements change (and the name would no longer be used in the git repo prefix) it's our occasion to change it and drop the baggage 20:07:04 Sorry I'm late... 20:07:05 On the other I think we can technically have stackforge things under openstack/* git repo prefix, beef up the requirements and *still* call the idea stackforge 20:07:10 Piet: you're in ! 20:07:16 and not forcing people to learn a new "experimental" concept 20:07:16 Thank you for your support! 20:07:31 but maybe OI'm overthinking this... Anyone else with same concern ? 20:07:34 that's a good point, and i gave it a good thinking about, but i also think it would be more confusing to keep it.... it actually adds one more thing to the giant pile of things people think stackforge is 20:07:46 yeh, it seems more confusing to keep it honestly 20:07:56 Piet were you able to address Diana's concerns 20:08:02 I'm also not sure "experimental" is the right term to describe it tbh. Absence of maturity is not the only reason to be in stackforge. 20:08:04 because it will mean something different to people that were here before the change, then those after 20:08:15 can you outline the confusion around the name stackforge? 20:08:23 and there is no "experimental" requirement in the experimental equirements 20:08:28 (sorry all, super slow wifi) 20:08:38 of all the things we have confusion around, I had been feeling stackforge wasn't one of them 20:08:39 anteaya: is that a question for me ? 20:08:43 ttx: well, i'm interesting in projects becoming openstack projects under the big tent; the tc said "we need a place for experimental projects" so i added that. 20:08:43 retiring the name is a good idea, but I see ttx's point about "experimental" 20:08:44 the room 20:09:03 ttx: i honestly don't know that i'm particularly interested in providing hosting for projects that don't want to be part of openstack in some way. 20:09:03 annegent_: i think the suggestion of confusion is keeping it and changing the definition of it 20:09:09 anteaya: I agree that stackforge is a known quantity and we are about to force people through a new concept (again) 20:09:10 Hi, Anne. We addressed the concerns internally. I believe at least some of her comments with about internal process 20:09:17 Oops.. anteaya 20:09:25 jeblair: ok, so that's just forward-looking 20:09:38 what is redefined for it 20:09:40 jeblair: so... test case, gerrit-dash-creator is that a thing that should just move to github under this model? 20:09:42 jeblair: there are projects in stackforge right now that are not really experimental 20:09:51 sdague: no, it's totally in service of openstack 20:09:56 the namespace would be changed but the not under the tc governace would remain the same 20:10:08 jeblair: ok, would it get flagged experimental? 20:10:26 ttx: agreed, for instance stacktach 20:10:37 exactly 20:10:39 sdague: if it wants to be? but it could also join openstack-infra if it wanted. 20:10:42 anteaya: true, but the introduction of big-tent and experimental is what I believe some are concerned about. FTR, I'm not one of those, so I'm just trying to express what I've interpreted here 20:10:44 which I believe is happy under stackforge 20:10:57 puppet-openstack is under stackforge. 20:11:09 jgriffith: thank you 20:11:10 Not sure it's "experimental" more of a perpetual WIP 20:11:18 oh hi 20:11:23 are we doing this? cool. 20:11:39 med_: it's being moved over since the project team was accepted. 20:11:42 * med_ thought lifeless sat somewhere else or would have fetched. 20:11:55 'k 20:12:07 we really can't hold the nova meetup to not do anything for an hour 20:12:16 so, I'm going to focus on the nova meetup again - we're starting up 20:12:19 so in summary I think we have nailed down the intention now, but we need to figure out the branding/naming 20:12:27 if you need me, get someone in the room here to shout 20:12:44 because that's something we'll have to communicate to the wider community as a ting, we can't really figure that out in steps 20:13:42 jeblair: what's the path forward for a project like stacktach, which is basically under stackforge to avoid the TC governance and rules ? 20:13:51 not because it's experimental 20:13:59 not because it's not really about openstack 20:14:16 should it becmoe "experimental" ? 20:14:24 it is kind of experimental, isn't it? 20:14:33 some say ess than ceilometer 20:14:36 less* 20:14:43 (rimshot) 20:14:45 I think we should reserve that status for projects that intend some day to become official 20:14:46 i think experimental should be things that intend to become not experimental 20:14:48 in terms of governance 20:14:51 I'm not sure stacktach fits that 20:15:00 why wouldn't they? 20:15:11 I thought that's why they wanted to avoid the TC rules (because they were experimenting & wanted to move faster) 20:15:12 sounds like a "find another home" situation if the project really didn't intend to become official for whatever reason 20:15:14 the barrier is quite low now. 20:15:26 s/didn't/doesn't/ 20:15:41 jeblair: so the answer is... get in or get on the highway ? 20:15:44 i don't think the tc is very effective at slowing projects down... 20:15:57 ttx: i think the answer is, it depends on the project. 20:16:05 we're just speculating about stacktach's motives 20:16:32 so many projects are on stackforge because they want to be part of our community, and we have now made it easy to be part of our community 20:16:43 yeh, I don't personally feel like openstack needs to sign up for free gerrit + ci hosting for any random thing. It's ok if some amount of stackforge doesn't fit, and needs to find a new home. 20:16:58 ok, but I think the point isn't about that one project, it's trying to identify what cases might come up and make sure the message is clear for all of those cases 20:16:58 i honestly doubt that whatever drove stacktach to think that stackforge was the right place for them still applies 20:17:08 I had thought that was part of our grow the ecosystem model 20:17:17 sdague: and I'd actually agree with that. I just think htey need to know about this discussion 20:17:24 I wonder if we should not have an email thread about this proposal, since it's currently flying under the radar of a lot of projects that will be affected by this change 20:17:25 the layer of things that were openstack but not under tc governance 20:17:33 Giving them the opportunity to voice their opinion of it before we approve it would be good, since it will directly impact them... 20:17:38 dhellmann: i would say that if a project has contempt for the tc and the wider openstack development community, then this is probably not the place for that project. 20:17:41 zaneb: nope, and ttx how do we know any project's motivations? 20:17:48 jeblair: I agree with that 20:17:54 I'm uncomfortable talking about a project without having a rep here to discuss their motivations. 20:18:01 jeblair: dhellmann agree 20:18:02 jeblair: I don't think opting out of elections and so on is expressing contempt 20:18:03 jeblair: I don't think 'contempt' is accurate 20:18:12 annegent_: let's say it's an hypothetical project 20:18:21 I think it is exerciseing an option for being in the ecosystem 20:18:32 edleafe: great, because that's the strawman that has been proposed, so if we can get a better one, let's do it. :) 20:18:35 and I had thought that was part of the vision to grow openstack 20:18:36 there are projects in stackforge that won't defer control over their project to the tc 20:18:44 ttx: there are motivations and attitudes throughout, stackforge or openstack, doesn't matter. 20:18:46 jeblair: fwiw, both pecan and wsme will likely move back to github, not because of contempt, but because they're not solely used by openstack 20:19:03 ttx: what sort of control will the TC be exerting on them? 20:19:15 dhellmann: and I don't think that's a great outcome tbh 20:19:29 edleafe: potentially anything 20:19:29 dhellmann: what motivates that? 20:19:43 dhellmann: i think they contribute significantly to the openstack mission 20:19:56 dhellmann: and we have lots of projects in openstack that are not solely used by openstack 20:20:10 jeblair: ok, well, they're not experimental and don't want TC oversight because this project is not the only one driving their requirements 20:20:21 jeblair: ttx just curious, if they're widely used elsewhere, and still open on github what's the down-side? 20:20:22 and it sounds like stackforge is closing? 20:20:31 edleafe: we wield the "do that or get out of openstack" threat, we've just been pretty conservative at using that nuclear optoin so far, mostly because we didn't have that many projects 20:20:32 maybe I'm wildly misunderstanding the intent here 20:21:01 dhellmann: At first thought I personally wish "more" would find homes outside of the OpenStack umbrella so to speak, it means they're diverse and useful in other places (I think) 20:21:23 jgriffith: note the naming guidelines oslo uses, for just that reason 20:21:27 dhellmann: the intent is primarily to put all the projects in the 'openstack' namespace so we can stop moving them around all the time :). secondarily, it's to push projects that should be in the big tent into it. 20:21:41 so perhaps we need a word that's not experimental and a word that's not stackforge. 20:21:50 dhellmann: indeed 20:22:01 jeblair: ok, well, if you just want to rename their git repos I don't think that will be an issue, and "retirement" may have given me the wrong impression 20:22:06 jeblair: 'outdoor' projects (i.e., not in the big tent)? 20:22:10 jeblair: what if we just moved all of stackforge/ to openstack/ and kept stackforge the same ? Solve the technical problem first ? 20:22:23 side-shows :) 20:22:30 jeblair: note, there wasn't any complaint, it isn't a big deal for those projects 20:22:40 we could have a stackforge.yaml that lists them so that we know which is which 20:22:58 dhellmann: yeah, we're clearly still trying to figure our way here 20:23:04 ttx: or we could do what we do now, and not include them in project lists at all 20:23:17 edleafe: I like outdoor, but I'd rather not change names if we can avoid it :) 20:23:27 dhellmann: right 20:23:29 jeblair: sure, I guess my point was just that it may be natural for some projects to decide to take the opportunity to move 20:23:39 ttx: just a suggestion :) 20:24:05 dhellmann: that's fine -- it's only the suggestion that we might make a missstep that would cause a project contributing to the openstack mission to think they _had_ to move that concerns me 20:24:37 My take on this is that to solve an immediate problem (repo renames) we design a chnage that will have lots of side-effects on our community and need to be carefully considered and discussed 20:24:40 jeblair: yeah, that wasn't as clear in early drafts -- I'll review it again with that in mind 20:25:09 and I'd like the discussion on that to take some time, but I think solving the repo rename issue can be done fast 20:25:24 dhellmann: it's changing. earlier, i would have expected those projects to join the big tent. 20:25:50 jeblair: anything preventing a massive stackforge rename to happen tomorrow ? 20:26:04 jeblair: I think the pecan team is pretty happy with the relationship they have with the community now, and aren't looking for more oversight that a move like that would imply 20:26:47 probably the biggest hurdle to a mass rename is scheduling/messaging 20:26:50 ttx: just a few hundred person-hours of work :) 20:26:56 would it buy is anything to just stop adding new projects, and continue doing renames as-needed? 20:27:01 jeblair: that we would have to do anyway, right ? 20:27:32 at least if we do it all at once, we can rip off that band-aid and have it over with rather than death by a thousand cuts over the next several years 20:27:39 ttx: right -- we're okay signing up for the renames, just not continuing indefinitely :) 20:27:44 ttx the hope is that a project aimed for teh openstack namespace doesn't expect a rename as part of their workflow 20:27:46 fungi: that makes sense 20:28:12 jeblair: right, we would just do a one-stop rename of all stackforge/* to openstack/* 20:28:12 ttx namespace, big tent, offical - pick your term 20:28:23 so it seems like the tc's feeling this week is that it doesn't want to change anything about stackforge at all, and would like to keep the stackforge "program" as-is but move it into the openstack namespace to facilitate migration? 20:28:28 still call it stackforge and then have a longer discussion on the future of that 20:28:54 jeblair: I think that would get you to 80% of your objectives, twice as fast 20:29:25 jeblair: My feeling is that we have to take more time to discuss changing stackforge into anything else 20:29:33 including a ML discussion 20:29:42 and we can solve the immediate problem faster 20:29:56 ttx: i suspect we will lose the inertia to change it; i don't think anyone _really_ wants to change anything about it. 20:30:06 I would like to see a ML discussion, too. I think eventually it does make sense to "close" stackforge in some sense and retire the name. 20:30:21 jeblair: maybe. once we remove the pain, the fuel will be gone 20:31:02 my hope is to convince everyone that the big tent is big enough for all of these projects, but that can wait. :) 20:31:06 jeblair: so I would pick one of two ways: continue with the larger change and start a discussion on the ML about it... or pass a resolution for the aggressive renaming of the git namespaces 20:31:22 without changing the governance behind it 20:31:29 at least in a first step 20:31:44 do we want a stackforge.yaml file, or just, no file for stackforge and you add yourself to projects.yaml when you want to join the tent? 20:31:53 I think the latter 20:32:02 dhellmann: me too 20:32:06 I could do with bot 20:32:07 h 20:32:27 I've met with a number of very confused folks lately, and I feel like changing stackforge today would be the straw that breaks the camel back 20:32:34 but those same people never cloned a repo 20:32:44 so the namespace migration would not affect them 20:33:19 ok, we need to move on to other agenda items... 20:33:20 so next version: stackforge continues as-is, no registry of stackforge projects, but stackforge projects are created in openstack/ namespace 20:33:21 does anyone know how many stackforge repos there are, roughly? 20:33:39 i'll have that ready by next meeting 20:33:45 dhellmann: 326 20:33:48 jeblair: yeah, with renames for existing projects to be scheduled in short order if you want to include that 20:33:48 and moved over in a short timeframe so that we don't keep both 20:33:51 minus a few that haven't moved over 20:33:55 jeblair: that's a pretty exact estimate :-) 20:34:05 deceptively exact ;) 20:34:17 jeblair: do you have enough to move forward, or need more on this topic ? 20:34:24 ttx: got it, thanks 20:34:29 309 repos in the stackforge namespace as of today 20:34:31 there are quite a few repos that are scheduled to move already :) 20:34:43 oh, you're counting attic probably 20:34:44 #topic Adds guidelines for project and service names 20:35:01 (would be great to identify dead and move them to attic directly) 20:35:07 #link https://review.openstack.org/201160 20:35:10 annegentle: would you like to introduce this one ? 20:35:21 ttx: sure! 20:35:23 I think the TC oversight is the big thing 20:35:33 bah, way back on discussion, sorry. 20:35:35 wait I'm not nearly as enthusiastic about this topic as it sounds! 20:35:37 :) 20:35:48 not sure eating while chairing this meeting was such a great idea. Cold food seems to be the net result 20:36:14 ttx: welcome to my world 20:36:22 lifeless: it's a bait-and-switch scheme. Open the tent, bring the baton 20:36:36 control all the things 20:37:25 so.. anyone with questions on boring naming stuff? 20:37:35 So, partially it gets interesting with jaypipes last question. 20:37:49 I have a few remarks wit hthe application and the result of it :) 20:37:50 annegent_: can you explain the "Use modeul if it is consuming other services" thing? does that mean literally put the word "module" in the name somewhere? 20:37:51 "We don't want two OpenStack Compute APIs, but we could conceivably have more than one project that published *the* OpenStack Compute API." -- jaypipes 20:37:54 what's with the reference to the ibm style guide? 20:38:03 agree that using project name for the service is terribad 20:38:05 annegent_: I don't think jaypipes is right about that. 20:38:06 jeblair: in all writing circles you need a final arbiter 20:38:21 IBM is pretty much the only tech company besides Microsoft still publishing a tech pubs style guide 20:38:30 #link https://review.openstack.org/201670 20:38:31 usually in open source we would have used the old Sun Microsystems one 20:38:35 This one is a strawman showing how the application of the current rules would look ^ 20:38:36 annegent_: and it would help with choosing terms like this? 20:38:37 but Oracle didn't keep it in publishing 20:38:45 jeblair: bare-metal or bare metal? 20:39:01 jeblair: find an arbiter and let them decide rather than giving writers time to debate 20:39:13 this is like pep8 for names in documentation 20:39:17 annegent_: ah, i understand now. that may warrant an extra sentence in the governance change. :) 20:39:26 jeblair: :) I can do. 20:39:29 annegent_: in the strawman application reiew maybe "Image" for Glance and "Message" for zaqar feels a bit raw 20:39:36 Especially with Cue being "Message broker" 20:39:37 I'm also fine with removing the "module" rule but it does mean changes to existing docs. 20:39:58 ttx: I too felt like plural as a rule might be a better rule. Images Messages 20:40:04 annegent_: I'm not asking for a change, I just don't understand the statement there. 20:40:08 (well, I don't know if too is correct) 20:40:13 Computes! 20:40:29 annegent_: I think ttx means that "Message broker" isn't sufficiently descriptive, because there are a couple of things that are related to message brokers 20:40:37 dhellmann: ah 20:40:46 ttx: Computing, Networking, Imaging, Messaging 20:40:50 Storing 20:40:51 cue is message brokers as a service, zaqar uses a message broker to deliver messages 20:40:55 see all kinds of rules we can make up 20:41:09 no I mean Service: Message and Service: Message broker sounds pretty... similar but still different ? 20:41:22 (and zaqar is also a broker, right? 20:41:24 ) 20:41:33 eep. I guess? 20:41:41 dhellmann: oh... ok... 20:41:50 * ttx is even more puzzles now 20:41:56 some of this confusion seems to stem from the old need to have a unique name for integrated projects 20:42:04 * jaypipes rejoins meeting... 20:42:08 right 20:42:08 hey jaypipes 20:42:18 maybe rather than a service name, we should just have a short description, and use the project name in the docs 20:42:20 perhaps cue should be "Message broker provisioning" or something 20:42:25 dhellmann: right I agree. But for docs we need unique names 20:42:36 annegent_: projects have unique names already, right? 20:42:36 jeblair: ++ and ditto for Trove, which is not a database 20:42:46 zaneb: right 20:42:51 annegent_: there are not 2 Cue projects 20:42:53 while magnetodb is 20:42:55 dhellmann: we avoid the use project name in docs so that users don't have to do a lookup for "what is trove?" 20:43:00 or not 20:43:13 dhellmann: "what is cue? I have to go to another place to look it up" 20:43:14 annegent_: I can see where that would be appropriate sometimes 20:43:22 zaneb: the distinction there would be, indeed, useful 20:43:25 (yeah, our codenames are decidedly unfriendly for new users/deployers) 20:43:29 dhellmann: it's a bad experience 20:43:32 sure, ok 20:43:35 for pretty much everyone 20:43:36 ttx: exactly, though not the only conceivable kind of database by a wide margin 20:43:39 so let's make more descriptive project names, then 20:43:41 i was confused as a newbie when we had 3 projects. 20:43:46 jeblair: heh 20:44:03 jeblair: I kept calling swift nova and the hateful stares finally made me stop :) 20:44:03 * dhellmann only pretends to know what any of these projects do 20:44:04 I still have to look up half of the project names 20:44:07 zaneb: I like provisioning. makes it clear it's not dataplane api 20:44:16 annegent_: hateful stares as a service 20:44:17 +1 20:44:23 so: nouns not gerunds (-ing) 20:44:40 service not project 20:44:43 foundations as a service is popular lately 20:44:44 be legal 20:45:01 no more "module" 20:45:09 ok, so how about we push that discussion to the review ? 20:45:10 annegent_: "be legal"? 20:45:23 dhellmann: just that you don't add OpenStack automatically to a service name 20:45:25 so far it didn't get that much attention, so it's still at early stages 20:45:27 It seems that one size doesn't fit all. Some projects provide a clearly defined service (compute), while others are fancier combinations that offer a blend of things 20:45:29 annegent_: oh, ok 20:45:29 dhellmann: that's "illegal" 20:45:43 annegent_: some of these rules would make more sense with these explanations included inline :-) 20:45:49 ttx: fair 'nuff. Anything I should patch today? Maybe remove modules. 20:46:00 dhellmann: oh maybe examples would be useful in the guidelines? 20:46:12 edleafe: is compute that clearly defined? containers in, containers out, containers sort-of-in ... :) 20:46:13 annegent_: I like adding provisioning where applicable 20:46:17 dhellmann: I can do that 20:46:17 annegent_: I would not presume to tell a doc expert how to explain things best. ;-) 20:46:28 dhellmann: ha, you're better at documenting governance than I 20:46:37 ttx: ok 20:46:37 ok, moving on 20:46:40 sounds good thanks 20:46:43 #topic New projects have to meet all existing policies. 20:46:44 lifeless: :) 20:46:46 dhellmann: ouch, not sure how i'd feel about that if i were you? :) 20:46:47 #link https://review.openstack.org/201766 20:46:53 I think that's just a clarification, and the suggested wording is an improvement 20:46:57 Still missing a couple votes last time I looked 20:47:03 ttx: angdraug had a request on that one that I think is worthwhile. 20:47:03 * ttx checks now 20:47:06 +2 for great consensus 20:47:08 jeblair: oh no offense meant to dhellmann :) 20:47:18 jeblair, annegent_ : I'm still trying to decide ;-) 20:47:37 jaypipes: could eb added as subsequent commit 20:47:39 :) 20:47:59 there is nothing wrong in current proposal, could just be more detailed. 20:47:59 jaypipes: I think angdraug's request is best as subsequent edits: they're asking for some existing policies to be better documented 20:48:16 just added comment earlier today that I can be mostly satisfied with making "all policies" a hyperlink to governance.openstack.org 20:48:21 jaypipes: which is fine, but in no way detracts from us saying that existing policies apply to both existing and new projects 20:48:24 Would be great if he submitted it directly :) 20:48:32 the rest should be done as separate fixups, yes 20:48:37 ttx. lifeless: sure, followup patch woul dbe fine. 20:48:47 ok, we have majority, will approve i 30 sec 20:49:03 #action angdraug to submit amendment to that guideline. 20:49:11 #topic Introduce the "deliverables" concept 20:49:15 #link https://review.openstack.org/202583 20:49:22 I'll let you read the commit message there. The idea is that we need to track user-facing units of software, which in some cases do not align to git repository boundaries 20:49:28 Hence the proposed introduction of a "deliverable" concept that maps 1:n to git repositories 20:49:38 I like deliverables! 20:49:40 And since that's the user-facing bit and tags apply to user-facing things, it makes sense 20:49:40 to apply tags at that level rather than at the git repo level 20:49:52 don't pay attention to the fact the change fails tests 20:50:02 we've already organized the new openstack/releases repository along these lines 20:50:18 it's because we need to evolve tools... I want to see if the idea sounds good enough that I can statr working on tooling changes 20:50:35 so I'm not looking for +1s now, rather for lack of -1s 20:50:55 ok 20:51:11 does that change generally sounds like a good idea ? let me know on the review and i'll continue working on it 20:51:33 concept makes good sense 20:51:38 i really like the concept. 20:51:41 and if i can bikeshed for a moment, i also really like it when lists are indented (like in the yaml spec) 20:51:45 ttx: sdague had a patch up for a new devstack tag that still seemed to apply to a repo, did you see that? 20:52:04 ttx actually starts to help me understand the various parts of a given project better 20:52:04 jeblair: please add that to review as comment, I had that file autogenerated 20:52:18 ttx: https://review.openstack.org/203785 20:52:28 ack 20:52:48 jeblair: I'd see all puppet-* from infra as a single deliverable for example 20:52:53 or not 20:53:07 frees us from repo boundaries 20:53:09 is that actually delivered anywhere? 20:53:20 not really 20:53:27 i think it makes sense for all the stuff released as part of openstack, though 20:53:31 it's continuous deployed 20:53:51 yeah, it doesn't make tat much sense for things that are not released, to be honest 20:53:57 yeah, i think releasing infra puppet-* is a long way down the road, if at all. 20:54:04 just because it's not packaged doesn't mean its not released, right? 20:54:24 I hesitated with having a special section for "extra-repos" outside deliverables 20:54:27 for specs and all 20:54:34 support rpeos 20:54:45 sice those are not "deliverables" in any sense 20:55:04 anyway, need to move on. Please review and let me know 20:55:10 #topic Workgroup reports 20:55:14 * Next tags 20:55:18 We had a meeting for the "next tags" WG last week, notes at 20:55:26 #link https://etherpad.openstack.org/p/next-tags-wg 20:55:29 if infra has a combined deliverable, it may end up being very large :) 20:55:31 Conclusion is we agreed on drafting a few new tags in the near future and push that to the TC 20:55:38 Details in the etherpad for those interested to see what we brainstormed 20:55:44 * Project team guide 20:55:50 I need reviews on that to push the changes I suggested, last time I looked only dhellmann did review 20:55:55 #link https://review.openstack.org/#/q/is:open+project:openstack/project-team-guide+branch:master,n,z 20:55:59 jeblair: any chance you could you look into that ? 20:56:05 We also wait for flaper87 to make progress on the Open development chapter (or post the current state) 20:56:12 Then it will be ready for publication 20:56:14 nice work 20:56:16 * Comms 20:56:22 annegent_: news? 20:56:26 I can write a post this week. 20:56:33 Also we now have a grouping link. 20:56:33 cool. UX! 20:56:51 #link https://www.openstack.org/blog/category/technical-committee-updates/ 20:57:00 nice 20:57:18 #topic Open discussion 20:57:24 jeblair: We have a few old repo-change governance reviews blocked on Infra PTL +1 : 20:57:28 https://review.openstack.org/#/c/196837/ 20:57:32 https://review.openstack.org/#/c/194284/ 20:57:48 not sure if those are blocked intentionally or just slipped through 20:57:58 There was an answer to the CLA question on the foundation list: 20:58:03 slipped through 20:58:03 #link http://lists.openstack.org/pipermail/foundation/2015-July/002030.html 20:58:09 haven't had time to parse it 20:58:34 i generally interpreted it as ACKing our interpretation from Vancouver 20:58:40 with some more detail 20:58:48 I'll give it a read 20:58:48 I couldn't figure out if somehow sdague posted to the board list? 20:59:09 board will discuss and hopefully officially approve the overall plan at board meeting next week 20:59:11 annegent_: no 20:59:14 yes, the "personalization" of the request was a bit disturbing 20:59:18 when is the board meeting? 20:59:21 sdague: tuesday 20:59:22 7/28 20:59:26 ok, cool 20:59:37 yeh, it seemed like mostly an ACK, I was happy with that 20:59:47 yeah, and hopefully on tuesday we can make it more official too 20:59:48 looks like saying it's "sean's request" makes it less than "the TC request" 20:59:59 (no offense) 21:00:11 right, but i don't see any reason to pick at that unless we didn't like the content 21:00:18 * jeblair moves that the TC thank sean for making that request :) 21:00:19 sure 21:00:25 ttx: yeh, well, I think the original request was pretty clear that it was generally TC supported 21:00:29 yep 21:00:31 I have a question about project for deb package proposed by zigo, when it could be discussed? 21:00:40 sdague: right, which is why I cringed at that subject line 21:01:00 anywya, out of time 21:01:01 yeah that was weird, but i say ignore it since the content is moving forward with what we want 21:01:08 sure, sounds good 21:01:19 personalization of requests from an elected body is a known tactic 21:01:31 #endmeeting