20:03:25 #startmeeting tc 20:03:26 o/ 20:03:26 Meeting started Tue Dec 16 20:03:25 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:29 The meeting name has been set to 'tc' 20:03:36 Our agenda for today: 20:03:42 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:03:51 err. 20:04:01 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:04:09 one should redierct to the other 20:04:18 #topic Project structure reform specification 20:04:26 #link https://review.openstack.org/#/c/138504/ 20:04:37 Morning 20:04:38 o/ 20:04:41 So... I posted patchset4 early on Friday, most of the discussion since then have been minor comments, not objections 20:04:52 So I think this is ready for us to vote on -- would be great to come to a decision before the holiday break 20:05:04 ttx: ++ 20:05:13 Any last minute question we can address in-meeting ? 20:05:33 o/ 20:06:34 If none, will approve when/if that reaches a majority, or we'll discuss it again next week :) 20:06:47 I have some reservations about how far we are lowering the bar for new projects. I like that we're lowering it, but I'd also like to include some things in this list like having an active team and such. 20:07:20 dhellmann: I'd say that's for another review, when we start drafting governance documents to drive that new thing. 20:07:23 I'll leave some more detailed comments on this draft, but I wanted to raise the issue because I'm worried we're pushing the pendulum too far. 20:07:43 dhellmann: that's this work item, right? 20:07:45 * Define new objective OpenStack project requirements (to replace old 20:07:45 new-programs-requirements.rst) (kilo-2 milestone, assignee tbd) 20:07:47 ttx: I would agree, except that this spec specifically calls out a list of things and then lists implementing that list as a work item 20:08:04 I'm looking at the list on line 109 20:08:05 dhellmann: the rules for accepting new projects will be defined in a specific document. This is just defining the direction , 20:08:19 in "Recognizing all our community is a part of OpenStack" 20:08:23 so we're all looking at the same thing 20:08:28 dhellmann: how does one define "active" team? 20:08:38 yeh, I guess I took the bits in this document as high level guidance 20:08:44 jaypipes: I'm not sure. How did we define it before? 20:08:53 right, it's more the general direction we are planning to go 20:09:08 So, talk me through the ATC bit again 20:09:09 dhellmann: I don't know. :) 20:09:12 i'd agree with dhellmann that the guidance listed seems to make a point about how low the bar is 20:09:16 sdague: ok, I did not take the wording that way: "we propose that those should [be] considered 'OpenStack project' ..., as long as" 20:09:25 I read it as saying that only projects formerly in the openstack namespace grant atc status? 20:09:25 dhellmann: yeh, I can see that 20:09:49 mikal: only projects in the openstack*/* namespace grant ATC status yes 20:09:55 mikal: this section is talking about new base rules for bringing projects into that namespace 20:10:03 mikal: I read it as "any project in the openstack/ code namespace grants ATC status" 20:10:12 mikal: not "formerly" 20:10:18 I think "those projects" is ambigious then 20:10:23 I am reading the same as jaypipes 20:10:31 And perhaps should be "those projects in the OpenStack git namespaces" 20:10:31 mikal: I added a comment to that effect 20:10:43 anteaya: oh yeah, look at that! 20:10:47 :D 20:10:54 mikal: I got ya 20:10:56 and what I'm worried about is that by dropping the bar *too* low, we dilute what "openstack" so far that it is meaningless 20:11:11 I definitely parse that para as saying that projects from the former program structure grant atc status 20:11:17 this brings us way closer to my understanding of how the apache foundation works than I think we should go 20:11:22 well, I think definition of the word openstack is a bit multifaceted 20:11:24 dhellmann: but you agree that this resolution is not forcing us to vote in one way or another in the future, right ? 20:11:31 ok, so can we do 1 of these at a time :) 20:11:33 ttx: slippery slope 20:11:36 dhellmann: +1 20:11:37 this resolution describes our intent 20:11:38 dhellmann: or at least punting to let other groups decide it 20:11:51 distros/products, and defcore, depending on how you look at it 20:11:52 ttx: I think a slight amount of word smithing 20:12:13 dhellmann: I'm fine with changing a blurb if you can propose something else 20:12:17 been doing that all week 20:12:20 yeah, I think if we clarify that this list is a set of principles, and that the actual rules to be developed later should be based on but not limited to these things, I could be happy with this 20:12:43 ttx; yeah, sorry, I've been fighting with setuptools all week 20:12:46 dhellmann: propose wording and I'll integrate it 20:12:49 ok 20:13:10 s/ as long as:/ as long as they meet an objective criteria for inclusion (one of the work items below). This might include items such as:/ 20:13:49 dhellmann: do you think that would match the intent correctly? 20:14:02 yeah, I like that 20:14:13 can I steal it to add to the comment I'm writing? 20:14:18 dhellmann: absolutely 20:14:37 mikal/anteaya: if you can give me the diff around "those projects" I can take the opportunity to clarify there too 20:14:41 though maybe it's worth clarifying ... how much more do folks see being added to that list? 20:14:57 russellb: not much, honestly. 20:14:57 maybe not defined in the spec, but curious what folks are thinking 20:15:00 ttx I did offer a comment with a suggested phrase 20:15:09 ttx: I put alternate words in my comment, is that sufficient? 20:15:14 reading 20:16:01 russellb: I'm not sure I see much more being added, mostly clarification and specifics on 'the openstack way' 20:16:10 russellb: I could envision us placing some kind of viability of the proposal 20:16:23 mikal: sure 20:16:31 * ttx rev5s 20:16:44 like, "we think this is sane" ? 20:16:46 markmcclain: it's got to be objective though 20:17:01 I think it will be a big mistake for us to not have any criteria beyond that current list. 20:17:07 sdague: right it is objective, but if we don't do that then the results will be dictated to us 20:17:20 yeah, this is the disagreement i was trying to expose .. 20:17:35 unless by "openstack way" you mean our code review, test, requirements management, etc. policies 20:17:45 what are the things that people suggest to add to that list? 20:18:09 markmcclain: the idea is to have a completely objective set of requirements; i.e. the opposite of what we have today. 20:18:11 jaypipes: what items from http://governance.openstack.org/reference/incubation-integration-requirements.html would you suggest we remove? 20:18:36 anything else while I'm at it ? 20:19:19 bah, pushed 20:19:30 dhellmann: not having a major architectural rewrite. Project's scope should represent a measured progression for OpenStack as a whole. Project should have a clear plan to prevent long-term scope duplication. 20:19:31 https://review.openstack.org/#/c/138504/5 20:19:35 jaypipes: I think objective is ideal but honestly if we set teh bar so low then the board and distros will apply the subjective criteria and we're left powerless to change it 20:19:51 dhellmann: the stuff about Programs. 20:20:17 well, that's the point of tags -- to help the board and distros and users sort through the large number of projects that are/will-be part of our community 20:20:18 i agree with what markmcclain is saying 20:20:21 jaypipes: I agree on the duplication item. I think I'm +0 on dropping the architectural rewrite. I'm less sure about the scope question; that probably should be reworded some. 20:20:35 markmcclain: I don't see that happening. I just don't. We are the ones that are recommending tags for the board regarding maturity, trademarks, etc 20:20:41 jaypipes: yeah, programs go away, but some of that may apply to the teams 20:20:47 because it's a problem now that we don't actually have a good solution for 20:21:08 dhellmann: major integrated projects have and continue to go through architectural rewrites often 20:21:15 dhellmann: i don't see how that should be a bar to entry 20:21:17 jeblair: we can add tags without changing anything else 20:21:26 Before discussing the next step, could we vote on the first one ? 20:21:38 ttx: ++ 20:21:41 I agree that's a far more contentious item 20:21:43 dhellmann: I'd like to see things like using oslo (where appropriate) and the global requirements list and that sort of thing 20:22:07 zaneb: ++ 20:22:12 devananda: yeah, that's why I'm +0 on dropping it 20:22:16 ttx: I'm mildly concerned that we we wind up not having a definition for how horizontal teams are managed 20:22:21 jaypipes: I wonder if our signaling via tag will be interpreted correctly when more folks live in teh openstack git namespace 20:22:33 ttx: not, mind you, that I expect us to grow any in the near future 20:23:02 mordred: most of them are code-backed those days, so I'd say, same as others 20:23:03 following common/expected processes (oslo, pbr, sphinx doc, etc) - this is not explicitly called out 20:23:03 ttx: it's possible we don't need codification there 20:23:15 markmcclain: I don't think it can get much worse than the existing binary integrated-release stuff, frankly. 20:23:18 but is what part of "follow the OpenStack way", in my opinion 20:23:18 markmcclain: so here's the thing, distros and others are making those calls already 20:23:56 mordred: why do we have to have a definition of how horizontal teams are managed>? 20:24:02 well ... they're generally based on the integrated release, that's the base guidance 20:24:07 jaypipes: not saying we do - only that we might 20:24:09 mordred: why does the TC need to micromanage that? 20:24:11 devananda: ++ maybe the "OpenStack way" and the "four Opens" should be separate entries in that list 20:24:21 ttx, mordred: some of them currently have scope beyond "what lands in their repos" 20:24:25 jaypipes: ^ 20:24:26 jaypipes: agreed…I just want to make sure we're not abdicating power that we wont be able to get back if we realize we're wrong 20:24:45 but largely, if we have: "will let multiple different teams potentially address the same problems" - what about when that's not desirable (we don't really want to grow two docs teams or two infra teams) 20:24:59 mordred: i noted that on the review 20:25:09 cool. I'll go look at that 20:25:09 sdague: agreed, but we do box them in a bit because of how clear we designate stuff (even if we all agree needs work) 20:25:13 mordred: because ... common sense and communication? 20:25:14 zaneb: it gets tricky if we codify all of those. example: should every project use flask or pecan? this is not obvious. should they all use oslo? probably less contentious. 20:25:21 mordred: i haven't gone back to respond to ttx's response though 20:25:22 mordred: that was addressed in one of the comments. When we say "open development" that also means "collaborating" 20:25:29 zaneb: so while it's worth describing the expectation, I don't think it's good to state specific tools 20:25:31 markmcclain: distros and ops are going to adopt parts of openstack because we stamp it, but because it's actually good stuff 20:25:34 jaypipes: yah - it's entirely possible the answer is "we don't think it's a problem and will dael with it when it is" 20:25:38 zaneb: otherwhise we'll just end up with a meta requirements list 20:25:39 mordred: which is most cases would prevent duplicate horizontal teams if useless 20:25:46 zaneb: and have to change it later 20:26:01 mordred: and yes 20:26:15 devananda: yeah, I'd be happy with something vague ('follow the OpenStack way'), but I gather a lot of folks want only objective criteria 20:26:38 well, since now those are more inspirational than a final list of criteria, I think we should be good 20:26:46 zaneb: I think mostly we'll want to call out what that is in the follow up 20:26:56 sdague: ++ 20:27:00 +1 20:27:40 right, I just want to leave room for actual discussion in that, and not paint ourselves into a corner with *this* spec 20:28:39 I think it's appropriately vague now :) 20:28:40 yep 20:28:56 sdague: right that's what we want ops deploying it because it is good stuff, I'm wondering if tagging is delays our decision proces until too late 20:29:21 so please cast your vote and we can start discussing what level the bar should exactly be set at. 20:29:50 i want to give it another in depth read and consideration, i'll vote tomorrow 20:29:52 because yes, while everyoen agrees there shoud be some bar, your mileage may vary 20:29:59 russellb: ack 20:30:58 I'll leave it open today anyway to give annegentle a chance to register her vote 20:31:17 since she +1ed the previous rev and couldn't attend the meeting 20:32:14 So, assuming this is approved, next step here is to communicate about the proposed way forward more heavily, so that it doesn't take anyone by surprise. 20:32:37 I think we'll need to do that both sides of the holiday break obviously 20:32:39 Then we'll probably tackle the bar height 20:32:46 If we do it this week and next we'll miss a bunch of people 20:32:58 mikal: ++ 20:32:59 mikal: yes 20:33:12 work item says end of dec / start of jan 20:33:20 ttx: oh, fair point 20:33:32 What about ttx doing an openstack hour youtube thing explaining it? 20:33:38 (in addition to email etc etc) 20:33:40 ew 20:33:56 you could wear a fun hat 20:34:02 fungi: I was going to say that 20:34:03 Sock puppets? 20:34:05 more likely a giant handkerchief 20:34:06 +1 for ttx on youtube 20:34:08 fungi: although I was going to say pointy 20:34:38 well, we could certainly do some IRC town hall thing 20:34:49 resurrect the irc all-hands 20:34:50 i think email is quite enough 20:34:52 so that people can throw tomatoes at me 20:34:57 jeblair: ++ 20:35:01 yeah, an ml thread should be fine 20:35:05 but yeah, blog+email is probably the most async 20:35:25 particularly because it can be drafted and comments solicited 20:35:46 Last questions/ comments on this topic ? 20:36:39 We can go back to it in Open Discussion, time permitting 20:36:42 #topic A look at proposed openstack-specs 20:36:47 ttx: thanks for all your efforts here 20:36:58 sdague: thx! 20:37:00 There are two openstack-specs proposals up for review: 20:37:08 #link https://review.openstack.org/#/q/status:open+project:openstack/openstack-specs+branch:master,n,z 20:37:16 So far I wouldn't describe them as heavily reviewed yet 20:37:38 TC members have +2/APRV on that repo 20:37:44 so we definitely should 20:37:58 * mikal adds those to his review queue 20:38:10 that said, we need PTLs to review those (TC is mostly there to collect votes) 20:38:18 not sure on the way forward there 20:38:18 can you/we socialize the hog guidelines to the ops ml for a couple of weeks before finalled? 20:38:25 I thihn the fly below radar of most teams 20:38:39 * mordred has added to watch list 20:38:39 s/hog/log/ 20:38:39 "I think they fly" I mean 20:38:40 ttx: should we bring it up at the project meeting? 20:38:41 ttx: mention those reviews in the release meeting perhaps? 20:38:51 dhellmann: jinx! 20:39:05 dhellmann, mikal: yes, was thinking we could have some recurring item 20:39:08 mikal: thought thief! 20:39:23 ttx: I like that. 20:40:25 OK, I'll make that happen, mention it in open discussion in meeting today and start doing that more regularly in futur emeetings 20:40:36 ttx: sounds like a plan to me 20:40:51 thanks! 20:40:54 That brings us post-holiday season probably on those. 20:41:00 Is any of those so urgent they can't wait until new year ? 20:42:12 I guess not 20:43:07 #action Cross-project meeting chair (so far ttx) shall put openstack-specs on the Cross-project meeting agenda as a recurring item 20:43:16 #topic Housekeeping changes 20:43:20 * sort oslo libraries (https://review.openstack.org/140934) 20:43:32 For that one, I'd say, whatever is the most convenient for updates. Will approve tomorrow morning unless someone -1s 20:44:53 #topic Open discussion 20:45:09 Anything else, anyone ? 20:45:23 Something we should be doing that we didn't do ? 20:45:45 o/ 20:45:52 zehicle: go for it 20:46:10 thanks - a reminder that for the bylaws changes, we have need for people to vote to get quorum 20:46:30 does not matter if they are for or against really, we need votes or everyone is effectively "against" 20:46:44 and the voice of the people who bother to show up will not be heard 20:47:15 so, please remember to "rock the vote" or similar as we get closer 20:47:49 * zehicle ends PSA 20:48:05 indeed, that vote will need significant publicity to reach quorum 20:48:34 part of this vote includes lowering quorum based on historical data 20:48:45 For the next steps of the project structure reform, from my various discussions with people I expect the most contentious item will be the definition (or lack thereof) of a compute-{core,base,thing,layer,ring}. The spec only says we will define tags, and leaves that question for the future 20:49:06 zehicle: do you have a link handy to the published version of the final proposed bylaws change? 20:49:17 * dhellmann has a local meetup this week 20:49:23 those word docs were so hard to read ... 20:49:50 I expect the exact definition of the bar to entry to not be that contentious (famous last words) 20:49:51 russellb: yeah 20:50:20 should have been plain text, reviewed via gerrit :) 20:50:22 russellb: who knew that ms word is a bad revision control system :) 20:50:26 ikr? 20:50:27 ttx: I think I probably want that bar a fair bit higher than a lot of other people 20:50:45 ttx: I commend your optimism :) 20:50:45 dhellmann: higher than Jay, as far as I can tell 20:51:02 ttx: I suspect others, too, but I may be less optimistic than you :-) 20:51:37 I probably want the bar higher than some, too. 20:51:41 It will be easier to tackle those issues once we have an idea of where we are going (the spec) and we cut the problems into smaller pieces 20:51:42 so, probably a worth while part of the setting the bar conversation is to make sure we keep the "why" around 20:51:49 ttx: do you have a format in mind for that discussion? 20:52:04 https://review.openstack.org/#/c/131422/1/reference/incubation-integration-requirements.rst was my earlier stab at lowering the bar a little 20:52:10 devananda: I think we can work from proposals and counter-proposals 20:52:17 sdague: ++ 20:52:21 ttx: I think seeing a few new tags in a concrete proposal would help set the conversation 20:52:25 devananda: first ML thread, then opiniojnated proposals, then consensual proposal, then vote 20:53:16 devananda: basically what we followed for the the spec. Except we had to insert a face-to-face-or-video explanation as step 2.5 20:53:45 so that we get a better idea of what was consensual and what was not 20:54:00 which i think in the spirit of openness, we may want to try to avoid that if we can 20:54:08 agreed 20:55:33 sdague: yes, in the end all that's left of this spec document might just be the "why" :) 20:55:41 yeh 20:55:51 dhellmann: I'm going to throw onto your review 20:56:17 sdague: comments, and not rotten tomatoes, I hope 20:57:48 OK, if nobody else has a comment, we can close early. I'd welcome chairing help for the next meeting if some of you can stay around. Not in the best shape to have a difficult discussion right now 20:58:21 dhellmann: yep 20:58:31 ttx: I'll be there 20:58:49 dhellmann: cool. If I pass out, just continue and ignore me 20:58:59 #endmeeting