20:06:15 #startmeeting tc 20:06:16 Meeting started Tue Mar 10 20:06:15 2015 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:06:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:06:18 o/ (might drop anytime) 20:06:21 The meeting name has been set to 'tc' 20:06:43 #agenda https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:06:49 #topic Add IRC channel policies 20:06:49 #link https://review.openstack.org/159930 20:07:18 so this had several +1s 20:07:35 and agentle_ suggested adding another explanatory paragraph 20:07:40 thanks for the revision jeblair 20:07:42 which i have done (i liked it!) 20:07:45 i did change one word 20:07:47 whew! 20:07:54 agentle_: hopefully you're okay with my editing you :) 20:08:09 oh sure! 20:08:12 +1 20:08:20 I am _not_ the grammarian about whom your mother warned. 20:08:34 ha! 20:09:16 i think this revision should be good to go 20:10:06 and once it merges, infra will work on implementing it for the remaining channels 20:10:17 though a lot have gone ahead and proactively made the switch to logging 20:10:33 #topic Magnum - OpenStack Containers Service 20:10:33 #link https://review.openstack.org/161080 20:11:01 They crossed all the boxes on the current requirements list 20:11:07 I am present if there are questions. 20:11:08 the question is more, are we missing any requirement :) 20:11:17 it's probably worth noting there is a thread on the -dev list that suggests that many members of the tc are not ready to actually approve new projects yet 20:11:21 don't really want to re-hash the dev thread 20:11:33 jogo proposed a new requirement related to team diversity, but I think they already meet that one, too 20:11:36 and want to work slowly through this process to make sure that we're not missing anything 20:11:58 ++ 20:12:01 ++ 20:12:08 it's interesting to note that I asked the questoin about being ready to process applications a couple weeks ago... and everyone sais we were ready 20:12:26 i think i was out a couple weeks ago due to travel fwiw :) 20:12:33 dhellmann: I think this is very diverse http://stackalytics.com/?project_type=stackforge&module=magnum&metric=commits&release=all 20:12:36 so I guess it's precisely the fact that we received applications that triggered this whole discussion 20:12:47 ttx: probably 20:12:47 ttx: I think we're ready to see some submissions, and now that we have, I want to have a chance to look at them and consider whether they make me think we've missed anything. 20:12:51 hence my resistance to freezing. 20:12:53 my suggestion is to use the criteria set in writing, so that new project leaders do not feel as if they are trying to hit a moving target. 20:12:58 dhellmann: ++ 20:13:18 so I don't want to freeze submissions, just go slow with voting 20:13:20 i feel like we generally are ready. i do agree that as we go through the first few, we should introspect. 20:13:29 Also the current set of rules is pretty powerful. Like we require open development. that may or may not translate into "diversity" 20:13:36 and yeah, i'm okay with going slow and making sure we are doing it right. 20:13:45 i guess i'm just disappointed we have no tags ... we promised a rich navigation of the big tent, and we have nothing 20:13:52 but that definitely translates into resisting open washing. cc:mestery 20:13:52 that was my issue ... was curious if anyone else felt that way 20:13:54 weak support so far 20:13:59 russellb: what tags would be useful for evaluating these proposals? 20:14:02 ttx: +10000 20:14:12 ++ to going slowly and introspecting. I'd like to be sure I'm not implicitly applying standards that we've changed, simply out of habit 20:14:14 ttx: See my ODL emial on that thread on the ML 20:14:27 russellb: i'm about halfway through writing a response to the thread. i agree we probably can't hash it out here, just letting you know i do plan on engaging :) 20:14:37 jeblair: thanks 20:14:42 mestery: we may still have to refine the "are you one of us" requirements into more precise terms, but I think the spirit is there already 20:14:46 yeah, i'll just stop now, don't want to duplicate .. 20:14:59 russellb: I was just discussing some tags that I'd like to add with dhellmann in -dev, which seems to have stale mated in whether or not the TC should curate the list of tags ... 20:15:11 ttx: Just watching out for OpenStack's back. 20:15:13 russellb: but that discussion will derail this one, so let's not go there now 20:15:13 If we think a project doesn't belong and there is no rule allowing us to keep it outside... we just add a rule 20:15:37 do we have any questions for adrian_otto since he's here and apparently willing to be a guinea pig? :) 20:15:41 I'm just saying.. processing applications is the pressure that will push us forward 20:15:46 russellb: I agree that I'd like to see a richer set of tags, and i'd like to see them actually agreed on, so we all know what we're looking at as projects apply 20:15:47 I am. 20:15:53 freezing them is the best way to stop making progress. 20:15:57 ttx, add a rule if reaction to a proposal, or in general? 20:16:00 adrian_otto: is it clear why we're delaying any final decision? 20:16:10 ttx: fwiw proposal was to freeze approvals, not applications 20:16:19 I'm proposing to enter the git namespace, not to acquire project tags. 20:16:26 s/if/in/ 20:16:36 so I'd like to clear the first hurdle as the criteria for that has been set. 20:16:37 russellb: ok, I misunderstood what you said then, but I thought we'd all more or less agreed to that already anyway 20:16:38 russellb: I guess"slowly processing them and expect delays" is close to what you want then 20:16:48 then we can decide about tags later 20:17:10 adrian_otto: yep, understood 20:17:24 adrian_otto: I don't think we have any tags that would apply to your project yet anyway. 20:17:49 I feel like rejecting Magnum would go contrary to the core of the big tent approach. Which is including projects that are obvisouly openstack projects and bahve like one 20:17:50 yup tbh, affiliate companies that are considering contributing to magnum are gating on git namespace adoption, not tags... 20:17:53 behave* 20:18:19 dhellmann: hopefully we'll have release model tags soon :P 20:18:24 If people stop resiting them 20:18:34 ttx: i agree -- from what i've seen, magnum is an excellent example of what i imagined would happen 20:18:37 ttx: you could just put those in the release management readme and be done with it :-) 20:18:39 we want contributrors, which is why we want git namespace, tagging is for a different purpose and audience then adding devs to our project 20:18:48 dhellmann: :P 20:18:53 right, you want to be official 20:19:06 and i was hoping we'd have a better system for communicating info about the official projects 20:19:09 they want openstack design summit space to continue collaboration 20:19:11 before we ramped up inclusion 20:19:15 but alas 20:19:20 ttx ++ 20:19:32 ++ 20:19:33 just trying to clarify, i completely understand the difference between the namespace and the tags 20:19:38 my new motto is "step out of the way, fix issues when they arise" 20:19:39 russellb: ++ 20:19:58 ttx: Do you run with scissors as well? ;) 20:20:25 and yeah, i am a little more shy after hearing and seeing some of the problems in opendaylight 20:20:37 russellb: ++ 20:20:44 it's a big mess 20:21:07 i would have hoped ODL would have been our champion open source SDN backend by now 20:21:09 but instead ...... 20:21:19 russellb: Yup 20:21:22 they're too busy infighting 20:21:30 too many cooks 20:21:33 markmcclain: ++ 20:21:44 markmcclain: And too many recipes 20:21:46 ttx: in the old world, we would have two meetings for project inclusion. I'm all for going slow with the first few proposals inthe new way, and not rushing a vote today, with just one meeting 20:22:13 devananda: oh sure, totally agree we shouldn't approve today 20:22:14 what are the considerations specific to magnum that would delay a vote? 20:22:17 i think no one expects us to approve this change this week, so i think it's fair to say this will also be on next week's agenda 20:22:19 i want confidence that we're not headed there, a really nice system for communicating maturity, stability, etc. would help 20:22:20 but we should raise issues today 20:22:38 russellb: ++ 20:22:48 if you'd like to revisit this, I'd like actionable requests to take with me 20:22:56 russellb: ok, that's helpful, it's messiness to avoid, sure. 20:22:57 russellb: we had very interesting discussion at the ops summit on that 20:23:00 adrian_otto: I need to learn more about the project, myself, so I just need some time to read up 20:23:02 russellb: ++ 20:23:34 adrian_otto: ditto what dhellmann said. I'd like to learn a bit more, review the code and arch, see what's doc and what's tested 20:23:37 ttx: cool, interested to hear more 20:23:43 is opendaylight in some way beingcompared to magnum? 20:23:52 sdake_: no 20:23:59 more openstack 20:24:05 i see thanks 20:24:08 basically none of this has been magnum specific, heh 20:24:19 otoh, I think part of the goal of opening the big tent is to not have the TC doing that -- so even though I am inclined to do that, for my own satisfaction, i'm not sure it actually has any bearing on my vote 20:24:37 which is why I'd like a tagging system that can represent that sort of information about a project 20:24:46 yeah, I'm not aware of any issues with Magnum right now, just with our own confidence that we've thought about all of the edge cases. I'd like to consider several of the applications we have right now before we start approving any of them 20:24:49 adrian_otto: I had a question on the release model you wanted to adopt 20:24:57 currently it's adhoc releases 20:25:06 well we hav eabout 10 corporate affiliations and about 5 more on the fence awaiting git namesapce 20:25:09 adrian_otto: would you keep that model as far as liberty goes ? 20:25:20 I want to accelerate the project so that is my agenda ;-) 20:25:34 we plan to tag releases upon each significant feature addition 20:25:40 devananda dhellmann: I thought the new big tent model meant not reviewing arch 20:25:44 so as much as I want to be able to answer basic questions about the maturity of the project, how it's gated, etc, I also don't want that information to contribute to gate-keeping 20:25:48 dhellmann, adrian_otto, ttx: would it make sense to put another application on the agenda next week and get back to magnum in 2 or 3 meetings? 20:25:48 jogo: exactly 20:25:54 and we will label these releases on the timing of our littered milestones in accordance with other projects 20:25:57 sdake: that's an interesting data point wrt: the diversity question and the chicken-and-egg a diversity requirement would create 20:25:59 sdake_: I reaching the point where I don't care about companies that wait to contribute until a project is official. 20:26:01 my understanding is that swift works like this. 20:26:13 "5 more on hte fence awaiting git namespace" 20:26:15 jeblair: I like that, sort of do a survey of what we have in front of us right now 20:26:28 As of our Midcycle we have seen contributions from 24 engineers from 13 different affiliations. There is about 52,000 SLOC in about 100 days of development. Full time contributors from multiple companies are contributing. 20:26:29 yes the bar is the git namespace 20:26:31 not the tags 20:26:40 jogo: but without tags to represent that information, I feel like I'll be in a position to say "I think thisproject should part of openstack, but I don't actually know anything about it" -- and that's weird 20:26:44 from folks I've talked with nobody cares about tags from a "will we invest" perspective 20:26:51 I'd really like to secure design summit space, as we have a lot to talk about. 20:26:59 adrian_otto: Swift also does a "final" cycle release, would you do that ? 20:27:09 i really wish design summit space wasn't pressuring approvals 20:27:11 devananda: it sure is 20:27:12 ttx: yes, unless there is a good reason not to 20:27:15 ttx: is summit space already set? or is there room for more projects to get designated space? 20:27:16 adrian_otto: I don't think we've made any promises about approving projects before this summit. 20:27:17 russellb: +1000 20:27:17 adrian_otto: ok thx 20:27:20 ttx: have we? ^^ 20:27:21 russellb: +1000 20:27:29 russellb: ++ 20:27:37 devananda: i currently have space left for 5-8 extra big-tent-entering projects 20:27:44 surely we can solve that without governance approvals 20:27:58 the others would have to apply for ecosystem project days space on the Monday 20:27:59 Can't we just have existing projects give up a few slots? 20:28:01 the design summit space is only half the issue 20:28:02 just with our collective knowledge of "these 5-8 projects seem to make the most sense" 20:28:06 Why force governance just for slots in vancouver? 20:28:06 actually, I don't want ANYTHING to be pressuring projects to join openstack. whether that's design summit space, or the perception that by changing their namespace, they'll suddenly be validated, get wide adoption, and flourish 20:28:09 ttx: good to have a number 20:28:11 the other half is those companieson the fence awaiting official git namespace approval 20:28:17 we also have statements of intent from new contributors who can begin upon inclusion to the openstack git namespace. 20:28:30 so our velocity can increase if we proceed. 20:28:41 which is silly, of course :) 20:28:43 For Vancouver since we are in the middle of the transition we could adopt an hybrid model to give 20:28:46 the only reason for that perception (by joining openstack/* i get adopters) is because the TC has been cautious about who it lets in -- that signals a maturity and readiness for adoption 20:28:48 russellb: ++ 20:28:55 russellb it is what it is - you know how managers think ;-) 20:28:56 russellb: ++ 20:28:59 russellb: regardless, that's how it works. 20:29:30 sdake_: we need to find a way to change that, because we don't want projects from single companies -- not that that applies in your case, but in general 20:29:36 devandanda you may have a point 20:29:46 sdake_: allowing every project that currently wants adoption into the openstack/* namespace will signal nothing, and have the opposite effect 20:29:49 our intent has been widely discussed at three public events, and I am convinced Magnum is acting in the interest of OpenStack cloud operators. 20:30:04 devananda: ++ 20:30:18 adrian_otto: "it's not you, it's me" 20:30:18 devananda: we didn't judge maturity or readiness for adoptoin though 20:30:25 We were notoriously bad at it 20:30:31 dhellmann ack - agree - although magnum has no "single major contributor" 20:30:34 ttx: we sure tried 20:30:35 it's just an overloaded meaning of the integrated release 20:30:41 we are evenly broken up into nice little pies :) 20:30:43 devananda: we have a set list of criteria that must be met. My question is which of these criteria do I need to do more to meet? 20:30:43 sdake_: right, like I said, it doesn't apply in this case 20:30:49 sdake_: I'm not saying that's actually bad -- it's just going to defeat the purpose which you said that companies have in wanting to change namespaces 20:30:51 and documenting that sperataely (as separate tags) is the solution 20:30:51 there were written requirements about testing, API stability, ... 20:30:54 dhellmann: i don't think they are healthy, but i don't think we need to exclude them. i think we can let new projects start up, and if they gain contributors, that will be reflected. 20:31:03 ttx: agree, so let's create those :) 20:31:17 russellb: and yet we included projects that were not ready. Because we are not the ones to judge. Downstream users are 20:31:22 sdake_: also, not disagreeing that that is the motivation many companies have. but they're not thinking "what if every project did this?" 20:31:23 jeblair: I don't want companies benefiting from our name without actually being a real open project 20:31:27 russellb: those should be requirements for tags. 20:31:30 dhellmann: ++ 20:31:34 * jogo wonders if there any actionable items that can be worked on for next week 20:31:38 ttx: we still had a lot of useful requirements that were captured 20:31:45 adrian_otto: I know. 20:32:02 ttx: we didn't judge based on that, but others perceived our judgement as having that meaning. and clearly, still do :( 20:32:10 but i think it's a big confusing (potentiall harmful) mess to open flood gates when we haven't created a single useful tag. 20:32:32 do you think that Magnum will harm OpenStack? 20:32:39 russellb: nobody said they would open the flood gates 20:32:42 ttx: completely opening the gates, which we're all hesitant to do, will, I think, create a raft of confusion until the ecosystem realises that openstack/* namespace doesn't mean what they think it means 20:33:11 so our caution right now is around that change. But honestly, didn't we all agree that opening the gates like this is A Good Thing? 20:33:12 So, it seems to me part of the problem here is that the TC has done a poor job explaining what the openstack/* namespace means. 20:33:20 devananda: ripping the bandage off will cause that to correct faster. 20:33:22 mestery: that is not true. We did that 20:33:23 Fixing that may be worth doing to clear confusion here. 20:33:26 jeblair: indeed 20:33:44 mestery: the new-projects-requirements clearly says what belongs 20:33:50 jeblair: however, I had hoped we'd have some tags in place, with which to stop the bleeding :) 20:33:56 ttx: If companies are basing their participation on that fact, is ti really clear then? 20:34:03 devananda: we did ... though for me it was qualified with "but don't worry, we're going to do a new thing that communicates useful information in an even more clear way than before" 20:34:06 It means you follow the 4 opens and help furthuring the openstack mission 20:34:13 mestery: they've always done that, though 20:34:17 ttx: Also, I mean we should do a better job communicating it externally perhaps, likely most people here know. 20:34:22 russellb: exactly. and we have'nt done that yet 20:34:23 And open washing is not one of the 4 opens 20:34:28 ttx: lol 20:34:30 as is open core 20:34:35 ttx: It'st he fifth open, the one we don't want. :) 20:34:35 also, the TC doesn't even all agree on how to do that :( 20:34:37 devananda: *nods* ... that's my objection 20:34:43 russellb: and i don't blame you for expecting that, it is the first item in the resolution. :) 20:34:47 ttx: oh, that's a good one, we should make sure open core is listed as a no-no 20:35:03 dhellmann: it is patr of the 4 opens. You should read that 20:35:10 * mestery wonders how he can get Open Washing into the governance model as a no-no as well :) 20:35:11 russellb: based on that objection, I would say, we should block all new service project proposals until we have a suitable set of tags to communicate that information, and have applied them to existing projects 20:35:14 * dhellmann hangs his head in shame 20:35:15 ttx: so effectively we're describing a min-set of tags a project should have to be in the namespace 20:35:18 <<"Open source": we will not do open core.>> 20:35:20 devananda: ++ 20:35:59 so I _think_ I know what open core means, what does open washing mean? (I'll bite) 20:36:23 i just learned that term myself, heh 20:36:23 ttx: Is it the bit about the libraries restricting its use? 20:36:29 Heh: Open Sourcing a minimal version of some proprietary item. 20:36:33 Open Washing: ^^^ 20:36:34 i think we need to stop thinking of the git namespace as a part of a project's evolution 20:36:49 +++ 20:36:53 russellb: but also, I believe, based on my conversatoin in -dev an hour ago, that dhellmann disagrees -- which, I am guessing, is why he's hanging is head :( 20:36:56 jeblair: ++ 20:37:03 jeblair: yeah that's really strange to me, what rights/privs come with the github namespace? 20:37:14 jeblair deifne we - tc or openstack ATCs? :) 20:37:18 jeblair: I would prefer the namespace to be a statement of intent, and a committment 20:37:19 adrian_otto: is this a perception / education we need to understand? 20:37:31 devananda: our lack of consensus/clarity isn't giving me a lot of confidence that all of this will just get cleared up naturally easily enough 20:37:32 devananda: no, that was in response to ttx. I'm still banging my head on the desk in response to that conversation. ;-) 20:37:41 dhellmann: oh. lol :p 20:37:46 devananda: well put. 20:38:04 dhellmann: hey, i'm trying to create some bandages here ... I guess you'll need them, too? 20:38:15 sdake_: all of us :) 20:38:29 devananda: I support the idea of intent, but I think we need to be more clear about what we want that intent and commitment to be. That's not the same as saying we need tags. 20:38:30 agentle_: Look, Magnum is run as if it were any of our beloved OpenStack projects. We want a way to signal that. We want to participate in the same PTL elections, the same Design summit, just as we do everything else in the OpenStack way. 20:38:37 devananda: an ice pack? :-) 20:38:38 devanda I think fence cmopanies see the openstack namespace as intent 20:38:46 agentle_: afaik, there is now no actual (legal, governance, or otherwise) difference in the name spaces -- but in the eyes of hte community, there still is a perception of difference 20:38:52 i think companies see namespace as == official project 20:38:55 tags or namespace, you're just shifting the place where companies will look to define openstack, if the namespace is too wide open, tags become the new namespace, you're just shifting the target. Currently nothing is really changing but terminology. 20:39:02 and it is our responsibility to make consuming those projects sane 20:39:04 adrian_otto: please keep in mind, most of this discussion is meta, and not related to what you're doing! :-) 20:39:04 accepting magnum is a way to kick off Big Tent in the spirit it was conceived in. 20:39:07 but specifically, i think the new requirements are a big step in clearing the namespace thing up. i am hesitant to say we should create a bunch of specific tags and require them so that the net effect is that we have the same process as before. 20:39:13 yeah, it's not the git namespace, it's being official 20:39:15 whether that's by restricting the list, or with a rich set of info to help people figure it out 20:39:15 dhellmann: ack. 20:39:18 those who want a gatekeeper for committing resources will pick something to base that decision on. If the TC does not give them something specific they will pick something on their own. First it was 'integrated/incubated', then openstack/* namespace. 20:39:24 adrian_otto: practical question - has Magnum committed to maintaining API compatibilty across releases? 20:39:34 jeblair: +1 from me 20:39:44 Ops summit wrapping up here, might have to leave wifi coverage 20:39:47 dtroyer: Lets give them a magic eightball, it will be easier for them :) 20:39:59 devananda: we have not discussed api changes beyond the fact that that RPC messages will be versioned. 20:40:00 david-lyle: yes, but with tags, we can be more precise in what is communicated 20:40:04 david-lyle: it's not just "in or out" with tags 20:40:05 jeblair: +1 to focusing on the new-projects-requirements.txt rather than tags 20:40:19 I can tell you that no API changes are contemplated. 20:40:38 requirements say "diversity is necessary" while tags would say "here is the level of diversity" 20:40:43 devandanda imo yes we will but as adrian has mentioned it has not been discussed 20:40:44 devananda: in some way it will be 20:40:48 basically admitting that diversity is optional 20:40:51 if it would be helpful to reach a commitment on that point, our team meeting is today, I can raise it for discussion. 20:41:00 dtroyer: the next thing they will gate commitment on is our tag for whether or not something is allowed to use the trademark. 20:41:02 adrian_otto ++ 20:41:31 whatever system you create will be gamed 20:41:39 dhellmann: in absence of something like lsell described in the ML thread, exactly 20:41:40 but we are not gaming - we have a legitimate project 20:41:43 adrian_otto: I don't think we want to lock you in to making no changes, but a statement about maintaining the old API for some period would be good 20:41:54 so, new-project-requirements == requirements, tags == optional things. i think the optional things are just as important, as it's the set of things that helps you figure out which projects have reached a higher bar. 20:41:59 I think we can all agree to that 20:42:00 so i don't like just putting those aside 20:42:06 sdake_: Sadly, you're 100% right on the gaming thing. 20:42:06 and I insist -- the requirements are the minimal set. We still vote as humans 20:42:22 adrian_otto: yea, REST API compatibility, and testing of an upgrade path would all be good things to be clear about 20:42:23 russellb, ttx: those are both good points 20:42:25 and if we can't communicate useful information about varying bars projects have met, then i think the whole big tent is a disaster 20:42:28 So a project that does meet requirementsbut we don't feel belongs in... we reject 20:42:36 adrian_otto: not saying you need them now - just be clear about where the project is at, and where it's committed to go 20:42:53 ideally we then document that as a new requirement if we can 20:42:58 russellb: ++ 20:43:02 devananda: ok, we are < 4 months old in terms of code contribution, and about 1 year old in terms of ideation. 20:43:21 but in the end we are elected to make the choice, not create a game where people can get what they want and what we don't want in 20:43:33 i'd like to wrap this up in the next few mins... i think we've come as close as we can to giving adrian_otto tangible things to work on (which is very little while we continue to get our own house in order) 20:43:37 adrian_otto: ah! that's also really helpful information - and certainly sets a background to think about API compat on :) 20:43:42 ttx: Well said 20:44:00 can we decide whether to put magnum on next week's agenda, or defer for at least 1 week? 20:44:16 and again, Magnum is the wrong background to have this discussion on, since they do I think belong. 20:44:22 w.r.t. to the openstack git namespace, what really comes with that is non commercial trademark usage. 'Magnum a X for OpenStack' versus 'OpenStack Magnum'/'Magnum an OpenStack project' etc. 20:44:52 jogo: I don't think so, but that's the board decision 20:44:52 adrian_otto: it also raises an intersting question to the TC: should the age of a project's codebase ,how long it may reasonably have been in use by anyone, be a critera for inclusion? 20:44:56 ttx: agreed. i favor deferring magnum until after next week at least partially to help remove them from the focus of our disfunction :) 20:45:06 jeblair: :) 20:45:07 (right to call yourself openstack whatever) 20:45:11 +1 to defer 20:45:13 I dont think we've discussed that before ,but it's definitely something I have thought about w.r.t. younger projects in the past 20:45:14 ttx: through no fault of magnum's I think we should until the 24th 20:45:33 devananda: for inclusion no, but i think that's related to communicating maturity (optional higher bars == tags) 20:45:34 24th ? 20:46:01 ttx: that is how the old bylaws worked 20:46:04 russellb: what if someone proposes a project whose first commit was one day before the proposal? :) 20:46:05 next meeting is the 17th. Can't that work? 20:46:06 Also I'd like people complaining about lack of tags to actually statr being part of the solution 20:46:14 devananda: heh, fair 20:46:21 devananda: so maybe some bar there :) 20:46:27 required bar i mean 20:46:29 adrian_otto: they are saying they need time to think 20:46:31 ttx: I started drafting some tags. then started talking with dhellmann ... I'll post them anyway (WIP) later today 20:46:44 adrian_otto: they are also saying they are trying to help you achieve your goal 20:46:54 I expect ops to start submitting some soon too 20:47:10 anteaya: tx 20:47:15 adrian_otto: sure 20:47:16 adrian_otto: yes, i personally don't think we will be in a position to approve magnum by next meeting, so we should work on getting ourselves into a position where we can. 20:47:28 adrian_otto: everything to me says, right now, good to go -- but I am also being cautious about all our new processes 20:47:29 ttx: I wonder if we actually need to get folks together with higher bandwidth to hash out the initial base of tags 20:47:29 I'm also considering moving tags off the "governance" repo to a project catalog repo 20:47:50 and have a motivated subgroup work on htat 20:47:56 ttx: ++ 20:48:06 So congress and few others were asked to wait until after security team ran through the new incubation process 20:48:10 because as dhellmann syas, it's documentation, not governance 20:48:18 ttx: and I agree with dhellmann on that 20:48:26 it's documentation that makes the governance approach sane 20:48:29 * dhellmann stops banging his head on the desk 20:48:32 Should I be submittjng a proposal now? 20:48:33 ttx: but relatedly, I think the definition of what the tags are IS governance 20:48:36 without it, governance is a pile of fail 20:48:49 #agreed defer vote on magnum until after next tc meeting 20:48:51 pretty tightly coupled 20:48:59 devananda: that will be next discussion :) 20:49:07 ttx: because that is how we set the direction that projects work towards, and the constraints in whch they are incentivized to communicate up-and-down-stream 20:49:18 russellb: I'm looking forward to seeing a list of useful governance related tags. Only ttx's about defcore has been mentioned so far. 20:49:25 personally I think as long as we continue to listen to each other, we are succeeding 20:49:45 what we haven't been able to do is manage the expectations of the crowd 20:49:51 dhellmann: and tags that we would actually be the right people to maintain. Quite rare beast 20:49:53 anteaya: ++ 20:49:59 ttx: ++ 20:50:33 i think we have conveniently run out of time to address ttx's release tags in this meeting 20:50:33 dhellmann: I'm all for the TC being called on dispute resolution if tags are misplaced, rather than being a bottleneck in the tagging process 20:50:42 hence my new motto 20:51:00 but as a reminder, here they are: https://review.openstack.org/#/c/157322/ 20:51:07 read the new patchset :) 20:51:07 ttx: if a tag can be misplaced, it's not objective enough to be useful 20:51:08 'its easier to tag than ask permission' ? 20:51:10 "step out of the way, fix issues when they arise" 20:51:10 how will next weeks discussion be different? 20:51:31 should we schedule some separate time to discuss tags further? 20:51:39 jogo: that is unclear to me 20:51:46 ttx: you've said there's some discussio happening on that at the ops summit - 20:51:53 except I'll stand at my desk rather than on this uncomfortable chair 20:52:02 let's see where the thread and the ops summit put us at next weeks meeting 20:52:08 devananda: yes, like "how to define maturity" 20:52:14 and if we feel then that we need special time, let's decide then 20:52:28 ttx: great. if there's a way for remote participation, consider me interested // let me know 20:52:42 in the mean time, let's move on 20:52:45 #topic Other governance changes 20:52:52 #link Add the new developer-reference repo to the TC list https://review.openstack.org/161009 20:53:05 oh neat that was abandoned 20:53:16 #undo 20:53:16 Removing item from minutes: 20:53:23 #link Add the new developer-reference repo to the TC list https://review.openstack.org/#/c/161451/ 20:54:15 all; please review the release tag thing again as I'd like to post a final patchset if needed for qiuck approval. Hopefully will unclog the tag tap 20:54:45 dhellmann: do you think we will still have things in the cross-project specs? 20:55:02 unless we ca napprove it today, which I doubt given the remaining time 20:55:15 the SQL thing looks close to ready, but we're waiting for the ops event to end: https://review.openstack.org/152337 20:55:31 dhellman: AIUI, there's a difference between devref and specs, so they will coexist 20:55:34 the library stable branch policy needs reviews, but Oslo is going to be using this plan: https://review.openstack.org/155072 20:55:49 might also need to be sort of careful that things in the developer-reference repo don't unnecessarily overlap with the infra-manual repo (workflow documentation for example) 20:55:53 devananda: yes, separate repos 20:56:07 fungi: yeah, this is about things like how not to use eventlet in bad ways 20:56:08 dhellmann: ops like dropping downgrades 20:56:14 sean commented there 20:56:18 so it's ready to go 20:56:24 #link Remove py26 from PTI https://review.openstack.org/159936 20:56:26 ttx: ok, then we should get everyone to vote on that one unless it has enough votes 20:56:31 #link Remove reference to Jenkins in PTI https://review.openstack.org/159935 20:56:36 ttx: wow. I'm pleasantly surprised 20:56:40 dhellmann: is the developer-reference name a done deal? 20:56:57 dhellmann: dont wanna bikeshed on dev-ref naming 20:57:04 those are two, i hope uncontroversial changes to the project testing interface 20:57:08 agentle_: what do you want it called? 20:57:26 dhellmann: just worried, as always, on "contrib-dev" vs. "app-dev" 20:57:47 dhellmann: to be honest, i am having trouble distinguishing the things we've been putting in cross-projects specs from developer reference 20:57:53 agentle_: so far the content is literally stuff that only developers will care about 20:57:56 dhellmann: "making openstack, the good, the bad, the ugly" 20:58:00 dhellmann: they all seem like "this is a good idea and how we should do things" 20:58:13 dhellmann: but if people feel strongly there should be two, i can go along with that 20:58:30 jeblair: I originally wanted to just use the cross-project specs repo, but gave up after an hour of bikeshedding last week and created a new project. I would be very happy for the TC to vote to tell the PTLs to put those things in the existing repo. 20:58:41 dhellmann: jeblair: honestly get the best damn review team in place you can -- so I'd opt for cross-project over tc, no hard feelings :) 20:58:55 dhellmann: but yeah too many cooks happens in cross-project. 20:59:20 hm. is one more "this is a good idea" and the other is more "this is a standards document everyone should follow" ? 20:59:20 i'm not looking forward to arguing about which of those two repos something should be in :) 20:59:23 agentle_: so far I have not seen an overwhelming number of reviewers there, but this new repo will be managed following the same rules 20:59:30 jeblair: me neither 20:59:31 devananda: hm good point 20:59:39 jeblair: maybe I should go vote no on my own proposal 20:59:41 where "good idea" becomes cross project dev-ref, and "standards document" is really a TC thing 20:59:44 dhellmann: heh 20:59:48 dhellmann: you have emboldened me to do so :) 20:59:55 1 minute left: 20:59:56 #topic Housekeeping 20:59:59 also, I see the TC as agreeing to very few official project-wide standards 21:00:00 #link Add .pyc files to gitignore https://review.openstack.org/161023 21:00:00 #link Update the Infrastructure project homepage URL https://review.openstack.org/158371 21:00:00 #link Publish the extra ATCs for projects https://review.openstack.org/161465 21:00:20 where as we could produce a lot of "here's a better way to push a wagon" documentation 21:00:25 i spoke with fungi and am happy with the infra homepage change we deferred last week. 21:00:44 and we're out of time. thanks everyone 21:00:45 as long as the tc collectively is cool with the idea that not all project homepages are wiki articles 21:00:45 #endmeeting