20:01:04 #startmeeting tc 20:01:07 Meeting started Tue Mar 17 20:01:04 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:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:10 The meeting name has been set to 'tc' 20:01:12 o/ 20:01:15 o/ 20:01:17 Our agenda for today: 20:01:22 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:32 Hi 20:01:35 #topic (Final) Final rubberstamping of "Cross-Project spec to eliminate SQL Schema Downgrades" 20:01:42 #link https://review.openstack.org/#/c/152337/ 20:01:50 That was pending on the Ops Meetup and we got a clear go-ahead there 20:02:00 So unless someone violently opposes now, I'll consider there is consensus on this one and final-approve it now 20:02:18 +1 for final approve 20:02:21 ttx: what if I'm just violent? 20:02:33 o/ 20:02:45 mordred: you do have a history of violence 20:03:01 glad this is a virtual meeting then 20:03:11 * dhellmann sits back from the screen 20:03:17 last 10 seconds to register your +2 if you want it in 20:03:34 approved 20:03:41 #topic Tags 20:03:47 * Definition of the release:* tags (https://review.openstack.org/157322) 20:03:59 Looks like there is no opposition anymore on those, so it would be great if we could gather some approvals and move on 20:04:05 dhellmann and devananda +1ed an earlier version of the proposal 20:04:46 ttx: you removed the deprecation section? 20:04:59 devananda: yes, since there were no deprecation rules 20:05:07 and my wording there was confusing anne 20:05:14 *nod* 20:05:19 * devananda reapplies +1 20:05:42 * dhellmann ditto 20:05:48 While you vote, moving on to next topic 20:05:52 * Next WIP tags (http://ttx.re/facets-of-the-integrated-release.html) (https://review.openstack.org/163851) (https://review.openstack.org/163236) 20:05:59 There are several other tags being worked on 20:06:08 russellb works on a "team:diverse-affiliation" tag at https://review.openstack.org/163851 20:06:25 russellb: how is that going ? 20:06:43 fine, the feedback so far is positive, but just from a few folks 20:06:58 there's a few things to integrate, including your suggestion of adding a core reviewer diversity requirement 20:06:59 need more reviews before proposing final patchset ? 20:07:13 russellb: core diversity ++ 20:07:17 russellb: have you considered categorizing git trees instead of program groups? 20:07:27 sdague: that was another thing ttx brought up 20:07:33 sdague: I can see value in both approaches 20:07:43 since tags apply to projects ... i was proposing the tag is based on the overall diversity of the repos the team looks after 20:07:56 has anyone run the heuristic on existing key projects? 20:08:09 jeblair: it's in the patch iirc 20:08:10 russellb: that seems valid to me 20:08:10 jeblair: i did a pass in the existing proposal, yeah 20:08:17 not using proposed changes (like core team) 20:08:26 i scripted it after doing it manually once, heh 20:08:29 russellb: I like it by the way, even moreso with the core add 20:08:30 hah, it was _just_ below the point to which i had scrolled, sorry. 20:08:30 speaking for ironic, we have several repos in the project that have very different contributor diversity than the main server tree, or the group taken as a whole 20:08:33 but then it's also about fragility, and a repo which has just one company looking after it is more brittle 20:08:58 ttx: but a less active repo would be easier to save 20:09:07 ttx: I'm mixed on what i think the tag "means" but regardless 20:09:08 so overall diversity a better indication of overall health, i think 20:09:14 If you take a project team like iNfra, projects under it have a very different story 20:09:23 ttx: yes, that's a good counter example 20:09:27 not sure that's the case for any other team 20:09:32 russellb: I don't know if I'd agree, kinda think that should be left to other stats 20:09:42 I would suspect that oslo also has less diversity within some of the individual libraries 20:09:45 ttx: right, echoing a thing vishy said previously, oslo.messaging is a good instance of something which is very important but seems to not have many folks engaged on it, and I think that gets hidden if we lump all of oslo together 20:09:51 jgriffith: not embedding that into the tag definition 20:09:51 russellb: this is an example of a tag that looks useful, but is so easy to find from stackalytics that I wonder if we actually need to keep track of it manually? 20:10:19 dhellmann: we could expand that to abandoning this entire catalog 20:10:26 russellb: now you're talking 20:10:28 dhellmann: it's not that easy to find. If you combine commits/contributors/core stats 20:10:29 either there's value in making it easier to figure all this out 20:10:35 or not 20:10:37 i think there is 20:10:53 I think projects themselves are capable of handling non-diversity issues on their own repos (in the worst case by voting them off the island) 20:10:58 if people want to abandon the whole catalog, then i would question whether the proposed governance change is the right direction at all 20:11:02 but anyway ... 20:11:03 dhellmann: but then I expect some tags to be generated automatically (something like the requirements bot) 20:11:04 russellb: it's also prone to rapid fluctuations which may not reflect the project's usefulness, particularly in smaller trees 20:11:06 russellb: so let's build a page that pulls the data live, and let that be the info we show. Why track it manually? 20:11:08 ttx: russellb: keep in mind that all the openstack-infra projects' core groups have infra-core included in them 20:11:13 which brings back the diversity 20:11:14 so it makes more sense to me for the TC to be looking at projects as a whole 20:11:16 dhellmann: in the proposal i said it should be automated 20:11:20 fungi: I know some projects that this won't save 20:11:27 russellb: ok, I haven't hit the bottom yet, sorry 20:11:37 russellb: I think diversity of core team is a useful tag, and diversity of reviews and/or contribution to a project group overall is also useful 20:11:45 devananda: separate? 20:12:05 russellb: as a contributor, the "core diversity" tells me how likely my contributions are to be respected // or inversely if t's just one company running the show 20:12:13 Now that I've spiked your interest, I think the discussion should move to the review 20:12:14 russellb, dhellmann: i think it is important to _surface_ this information; i agree with dhellman that it seems we are moving information from one system of record to another. 20:12:17 russellb: as an operator, it tells me how likely this project is to die if one company pulls out 20:12:22 since we have a lot of ground to cover in meeting today 20:12:33 jeblair: you said it better than I did 20:12:34 and as a consumer, how likely I'm going to be in trouble if obe company makes a shift in intent 20:12:35 ttx: sounds good 20:12:35 russellb: but breaking down to individual git trees is far less useful to me in either csae 20:12:36 one 20:12:38 devananda: more than the review / contrib stats? 20:12:39 devananda: yeah 20:12:50 * mordred lets devananda speak more 20:12:53 please continue discussion on the review 20:12:56 devananda: it doesn't really... it just gives a data point 20:12:57 the actually core team membership seems less relevant to me than core team actions 20:13:04 while I can get that info from the various authoritative sources if i really want, eg. gerrit or git log 20:13:10 devenanda works on role tags, which are a bit of an opinionated taxonomy 20:13:14 that said from the feedback at the Ops Meetup, those are badly needed 20:13:18 I do think having documentation of it is helpful toour downstream consumers 20:13:36 There is room for other tags to be worked on 20:13:38 sdague: also, that. glance is a good example ... 20:13:43 For those who want to help, I described the various facets of the integrated-release comboconcept that we might want to independently describe as tags at 20:13:47 #link http://ttx.re/facets-of-the-integrated-release.html 20:13:48 I think what the TC woudl be vetting in this case is that the automated tag does reflect the data it says it reflects, yeah? 20:13:48 i'm in favor of opinionated tags personally :) 20:13:53 - Release model is now covered 20:13:57 russellb: ++ 20:13:58 - Co-gating is likely to emerge from sdague's work at https://review.openstack.org/#/c/150653/ 20:14:02 being opinionated is where we can actually add value 20:14:12 ttx: I was hoping to get back to that proposal more last week, but have been consumed by kilo-3 // feature freeze 20:14:15 - Supported-by should be proposed by all horizontal teams, to clarify what they actually support (defaults to "all") 20:14:16 if we're not opinionated *at all*, i don't know what our point of existence is anymore 20:14:21 russellb: ++ 20:14:22 russellb: ++ 20:14:32 - Stability should probably be expressed as opt-in feature/API deprecation contracts, I plan to work on that unless someone beats me to it 20:14:36 russellb: ++ 20:14:38 - For maturity, we now have an ops workgroup planning to work on that 20:14:56 So feel free to help in any of those areas 20:14:58 * russellb is very happy to see ++ on that, wasn't sure honestly ... 20:15:06 existentialist russellb 20:15:07 ttx: good write-up 20:15:13 russellb: but then jay is not around 20:15:15 * mordred hands russellb a fluffy llama 20:15:30 if anyone wants to take a stab at adding more role / usecase tags on top of my proposal, I wont object. otherwise, I will try to get to it in the next week 20:15:41 Which leads us to the next question 20:15:45 * Moving tags to a separate project-catalog repository 20:15:56 Once we have bootstrapped this framework, I think it should move to its own repository and be maintained by a specific team of people 20:16:01 What is the value in that? 20:16:02 i'm torn on this 20:16:02 A team interested in documenting project attributes 20:16:09 Because this is closer to documentation/reporting than to governance 20:16:12 Isn't that the TC? 20:16:14 partly because having it all together is convenient 20:16:20 and also because of the point i just made about being opinionated 20:16:26 and the importance of still being opinionated at times 20:16:33 it's not just a trivial task to pass off 20:16:43 I agree 20:16:46 if it is, again, our value is pretty minimal 20:16:47 well, that's about "stepping out of the way" I guess, and focusing on more critical tasks 20:16:50 most of the tags proposed so far are objective enough that there's no "opinion" involved 20:16:52 But also, its super important, so we should be shy about delegating it 20:17:16 we should keep things like whether we consider a project official, and whether we want the board to let them use the trademark. The rest of this is just "tell me what openstack is" documentation. 20:17:20 i did a bunch of thinking about this when I wrote up the roles / use cases tags ... 20:17:21 ttx: there's nothing stopping a community member from proposing a tag now... 20:17:24 it kind of comes back to, what tags actually exist 20:17:29 ttx: so how are we "in the way" at the moment? 20:17:36 ttx: i would think that even if the tc coordinates the efforts, they can still allow tags and input from other groups like ops/user committtee 20:17:44 mikal: I fear we spend all of our time rubberstamping stuff 20:17:47 I think by defining the set of tags ,what the criteria are, we're creating a policy 20:17:50 that's our governance 20:18:07 devananda: so we govern through taxonomy? :-( 20:18:10 so maybe we should keep it in governance until we find we're just rubberstamping all the time and deal with it then 20:18:10 we'll spend a lot of time approving tag changes 20:18:14 some of the tags are just informational, and could be delegated to automation 20:18:22 jeblair: good point 20:18:23 some will be opt-in, and the PTLs can self apply them 20:18:30 right now at least, i think the discussion around them is still useful 20:18:42 and some may well be set by other teams (like docs-supported, required-by-nova, or what ever) 20:18:54 yeh, I'm fine with keeping them in tree for now. Later migration can always be contemplated 20:18:55 could differentiate between tags that are obvious and don't need a full vote, vs. ones that are opinionated and need actual discussion and vote 20:18:57 I heard some feedback that nobody should touch tags because it's a TC thing 20:19:00 jeblair: we have several cross project specs that this group needs to approve. We're spending way way more time on tags than those technical issues. 20:19:07 the TC is still the arbiter if three's a disagreement, but we dont need to apply every single tag with a majority vote 20:19:09 so we need to better communicate how open the process is 20:19:13 there are some decisions asked of project-config reviewers that belong in the tc 20:19:33 as a project-config reviewer I am for keeping these decisions with the tc, re: tags 20:19:38 dhellmann: yeah, i could see us getting there; i'm just not sure we're there yet 20:19:48 It may be too early to spin it off 20:19:55 we haven't approved any tags yet :) 20:20:06 russellb: I can fix that now 20:20:06 so yeah, i think revisiting in a few months would be good 20:20:08 russellb: yup. we're approving too many of them 20:20:15 russellb: :) 20:20:26 ttx: in addition to better communication, I think we need to accept that there is a 6 to 12 month communication lag 20:20:26 mordred: not sure what you mean 20:20:39 russellb: me either- I was going for a droll joke, but it did not work 20:20:45 mordred: ok! 20:20:50 maybe when we're together in person someone will be able to explain why we're so excited about tags. They still feel like mostly a waste of this group's time. 20:21:05 but I'll stop harping on it, I guess 20:21:13 ttx: short of a keynote at the summit (or something similarly monumental) it's going to take a LONG TIME for these sorts of changes to trickle down to all the operators, driver contributors, etc 20:21:16 and *that* is why i'm hesitant to approve projects 20:21:22 we disagree on such fundamental things about this governance change 20:21:32 ttx: so the kind of participation that I think we need for this to work will not happen overnight 20:21:32 that i'm not convinced anymore we're in the right direction at all 20:21:43 devananda: come to day 2 in vancouver = ) 20:21:54 jbryce: ;) 20:21:57 russellb: I thnk the two are completely orthogonal - but that might be derailing this 20:22:15 OK, let's keep it in governance for the time being 20:22:18 russellb: so do we need a plan to get in sync again? If so, what is it? 20:22:19 and day 1 actually as well. but we have to have something understandable to present 20:22:47 mikal: i don't know ... maybe we should all write a bunch of blog posts :-p 20:22:53 russellb: sigh 20:22:54 NOOOO not again 20:22:56 russellb: that's definitely the right thing .... 20:23:10 ttx just wrote one! 20:23:13 I think maybe big tent was the wrong choice, and it should have been big yurt 20:23:17 so, really, perhaps an etherpad where we just get a sense of who agrees/disagrees on what 20:23:23 communication is important... not sure that a mass of blog posts is that 20:23:30 is there a single authoritative document that explains what the new structure is? 20:23:33 devananda: I'm tryin g to keep tabs on that 20:23:34 +1 to big yurt 20:23:34 lifeless: right, i was mostly kidding 20:23:39 then we set up some higher bandwidth disucssions to facilitate sorting that out 20:23:40 jbryce: yes 20:23:59 http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html 20:24:00 we got some negative feedback about high bandwidth sessions we had on this before 20:24:01 devananda: the spin-off disucssion was triggered with several discussions I had with dhellmann 20:24:03 devananda: I think the question is what higher bandwidth 20:24:04 we did some video calls at the beginning of the big tent discussions 20:24:09 fwiw 20:24:13 or i did anyway 20:24:17 russellb: clique concerns? 20:24:20 yes 20:24:22 russellb: I'm aware of that, and I can't for the life of me understand why 20:24:28 and the fact that they weren't open, just etherpad notes 20:24:31 it's a bit sparse, but here's a skeleton "product guide" repo I set up while talking with ttx about spinning this stuff out: https://github.com/dhellmann/openstack-product-catalog/tree/master/doc/source 20:25:02 I mean, people talk to each other. some times the medium gets in the way of actually sharing understanding and we need to use a different medium 20:25:06 the problem is we are so afraid of being accused of not open we can't get teh time to talk and understand each other 20:25:08 russellb: we might have to live with people seeing documentation after the fact if we want to resolve some of these bigger questions 20:25:27 Could we lock ourselves in a room before the summit and talk it through? 20:25:33 don' 20:25:35 mikal: ++ 20:25:37 there is so much noise we can't hear each other, or even ourselves 20:25:37 The morning before the board meeting perhaps? 20:25:37 if I have to fly somewhere to talk with someone in person, because we just can't sort it out on the phone .... I mean, that's lame, but I do it. 20:25:39 i don't want to wait until summit 20:25:44 ttx: thanks. i’ve actually followed these changes and that is another link i hadn’t seen yet. i think that’s really a big piece of the confusion out there is people have gotten bits and pieces from a mailing list thread here, an irc log there, a blog post on the other side 20:25:45 that's such a bad habit in openstack, heh 20:25:52 I think we can't wait until the summit, frankly 20:26:02 because we need clear signalling (eg, to jbryce ) before then 20:26:20 jbryce: the blog posts were all referencing the reference document (which was the spec) 20:26:26 jbryce: ++ 20:26:37 you should click links more :) 20:27:01 tfm links 20:27:15 So, about syncing... The thing is, every time I speak with someone supposedly disagreeing, they are actually not disagreeing 20:27:29 so it's more unfamiliarity than disagreement 20:27:33 ttx: that's an indicator we need to talk more I think 20:27:36 I agree with that 20:27:39 I have had the same experience 20:27:55 mikal: I think you should move to Europe 20:28:02 dhellmann: when we talked about a week ago, IIRC the only thing you disagreed on was where the tags are hosted, which boiled down to whether or not the TC should be governing them 20:28:10 or s/governing/required to vote on/ 20:28:11 i also worry that if we have a hard time understanding things among each other, good luck to the rest of the world 20:28:13 Don't talk. Post the doc on the front webpage of os.org 20:28:22 russellb: exactly 20:28:23 Rockyg: we don't control that 20:28:33 devananda: what has actually changed? there were a bunch of projects (including user-facing ReST APIs) that weren't incubated of integrated in the openstack/ namespace before, and soon there'll be a few more... 20:28:36 devananda: so far, 99% of the tags I have seen proposed are characteristics I would expect a product documentation team to be using to describe products. We're not a product documentation team. 20:28:45 mordred: if we asked nicely? 20:29:02 devananda: the only 2 tags so far that don't meet that criteria are "is it an official project" and "should it use the trademark" 20:29:03 likewise, we had a bunch of integrated projects before, and now we have an integrated tag. no change (yet) 20:29:05 dhellmann: i went after low hanging fruit, since it was proposed as a base requirement to start with ... 20:29:20 The only clear disagreement I heard was Doug thinking we the TC should get out of the product description business 20:29:31 Any other disagreement ? 20:29:32 russellb: right, and I think we all got tied up in the fact that Jay's blog post talked about tags and governance changes, but I don't think they're actually related at all 20:29:36 Rockyg: https://bugs.launchpad.net/openstack-org 20:29:51 dhellmann: i think some think it's related and others don't 20:29:56 anteaya: Thanks;-) 20:30:07 depends if you think tags are purely objective, or whether they're a means of providing more detailed opinions and guidance as well 20:30:09 i think.. 20:30:15 dhellmann: and the spec clearly presents them as separate efforts 20:30:20 * russellb tied them together 20:30:26 Rockyg mordred: we have been working on an update plan for openstack.org to cover these changes, but to be honest it’s been hard to even wrap my head around it and get a fully consistent description of it from the people i’ve talked to. 20:30:30 ttx: 2 points in the same spec though 20:30:33 We had a problem and took two efforts to solve it 20:30:42 (expand and focus) 20:30:48 russellb: sure, the guidance stuff is what I mean by product documentation though 20:31:17 ttx: I think I'm the only one who feels this way, and so I'm just going to shut up and let you get on with the meeting. 20:31:30 dhellmann: i feel like we're elected to be the ones to have opinions on behalf of openstack tech community, and communicate those 20:31:32 yay, no more disagreement, just a bit of confusion. 20:31:42 russellb: I'd agree with that 20:31:48 dhellmann: I'm probably misunderstanding you, because it sounds like you're saying the TC is not responsible for providing guidance about the projects that make up OpenStack... 20:31:50 russellb: me too 20:31:54 sounds like a doc sprint is needed to thrash out the two separate efforts, how they interact, and the vision thing, along with the spec. 20:31:54 russellb: yup 20:31:58 I think tags should be about guiding the project as to what the TC expects of them, rather than a 1-bit replacement for documentation 20:32:12 zaneb: yes 20:32:15 and to me, the tags thing was the new framework we were setting up for us to communicate those opinions 20:32:19 devananda: You are. We decide what projects are "in" the tent. After that, the entire community is responsible for properly documenting what we're building. 20:32:33 OK everyone, I'd like us to focus back on the agenda 20:32:39 * russellb sits down 20:32:41 zaneb: OK, that's not how they're being presented. 20:32:43 so that's what I meant earlier by we govern through creating tags and delegating the application of tags to the appropriate trusted / responsible parties 20:32:43 and move to the next (related) topic 20:32:45 sigh.. I was going to say something profound 20:32:52 jgriffith: bad timing 20:32:53 * annegentle is here, listening. Nothing profound about docs here. 20:32:54 * russellb takes it to a blog post 20:32:55 :-p 20:32:57 ttx: :) 20:32:58 russellb: heh 20:33:00 +1 to devananda 20:33:11 +1 to devananda too 20:33:12 * devananda sits down as well, lets ttx continue with agenda 20:33:36 (to end this discussion, I really think we are not very far away, and just need to talk more about it) 20:33:45 far from each other I mean 20:33:47 #topic New project teams additions 20:33:55 * Freezing or slowly considering (http://lists.openstack.org/pipermail/openstack-dev/2015-March/058689.html) 20:34:22 So I think it's pretty critical *not* to freeze the process, otherwise we won't make any progress in the next 3 months 20:34:34 Looks like most people on the thread agreed to slowly consider new project team additions, rather than freezing 20:34:40 We should go slowly enough so that we can refine rules as we go 20:34:47 i think we're making progress for the sake of making progress, even though there's a lot of confusion and potentially disagreement 20:34:58 on the project team addition side ? 20:35:03 yes 20:35:16 what disagreement is there there ? 20:35:26 russellb: I'd kind of agree, I don't see what it matters if new projects sit for a few months or not 20:35:31 but it goes back to different views on what the tag part of the spec means, how important it is, what things are included 20:35:32 * ttx doesn't see any patch proposed to the new-projects-requirements 20:35:38 * russellb sighs 20:35:48 That said, it's worth noting that the requirements as stated are base requirements we all agree on 20:35:49 i think we've half implemented our spec is all 20:35:52 i think evaluating the new additions is helping us see the system at work and understand what works and where we have disagreement. therefore, i think making slow progress should be our goal for the next little while. 20:36:01 but we always retain our ability to arbitrarily reject projects -- that is also why we were elected: to make the right call when needed 20:36:07 russellb: i agree that there’s some confusion and when i’ve watched the last few tc meetings it seems like different people have a different opinion of what has been agreed to 20:36:16 jbryce: that's my objection, yes 20:36:28 i wish i had a clear way to fix it up 20:36:32 i also think working through it slowly to bootstrap it could provide concrete examples of what needs to be answered 20:36:37 maybe a clear date to tidy things up by 20:36:58 I disagree with delaying project additions 20:37:02 categorically 20:37:04 russellb: "half implemented our spec" << yup, I agree 20:37:23 russellb: I think the spec is fully implemented. We added criteria for approving projects, and created a framework to describve projects 20:37:28 I'd agree with jeblair, in bound project consideration is kind of unit tests for whatever we're doing. I'm fine with going slow, but it seems like useful data. 20:37:32 russellb: but folks are still looking to us the TC to bless projects, despite some confusion about this whole big tent thing 20:37:36 ttx: see, there's disagreement after all :) 20:37:46 I think the only way we can get past people expecting us to bless projects 20:37:48 is to open the door 20:37:51 and stop blessing projects 20:37:54 if we add one or two projects, that's going to increase confusion, I think, because it loks like we will have blessed them 20:37:56 russellb: the spec was never about "finishing tags" 20:38:09 russellb: heck, I know. I wrote it 20:38:16 we can't agree on low hanging fruit, much less things that are actually more useful original bits of information 20:38:17 i think we should add 1, then 2, then 3, then a lot. 20:38:21 (tags that is) 20:38:25 by applying the criteria very broadly that we have agreed on 20:38:27 It was about setting criteria for new projects and set up a tag framework 20:38:27 OTOH if we rip off the bandaid and let in everything that meets our least common denominator, it's a very clear what we've just done 20:38:29 mordred: we are bound by the bylaws to bless projects for trademark use. Do you mean to apply that rule to that level of blessing as well? 20:38:37 jeblair: yeah i kind of agree 20:38:38 in any case, i'll abstain on new projects, not -1 20:38:44 * jogo finds it ironic we are weakening the openstack community software trademark while pushing hard for better commercial trademark usage, defcore 20:39:16 dhellmann: I do not think that letting a project "in" carries any implication about the use of the trademark - that's what defcore is working on 20:39:36 mordred: we are supposed to propose to the defcore committee which projects they consider, though, and so we're still a gatekeeper in that process. 20:39:41 we're just moving the gate 20:39:43 dhellmann: nor do I think it automatically confers in any of the documents I've see a suggestion from us to defcore or the board that we recommend these projects for trademark use 20:39:49 the "tc approved release" 20:40:11 I believe us "approving" projects has no bearing on that whatsoever 20:40:12 that said, i would like us to have a tag system in place before we rip off the bandaid. 20:40:18 I do not 20:40:18 mordred: I'll have to find it, but I do remember that being our responsibility to suggest which of *all* of the projects should be included in any trademark policy. 20:40:19 is the base they work from, in the updatedd bylaws 20:40:22 iirc 20:40:25 OK, let's focus on agenda again -- do we need a vote between freezing and slowly considering ? 20:40:29 I do not want to wait for a tag system for us to implement the system we have already approved 20:40:36 that is just us being policy wankers 20:40:37 mordred: i do not mean that we should have all the tags IN that system 20:40:39 ttx: I think a vote is a good idea 20:40:41 let's get it done 20:40:44 and do something 20:40:44 i think a tag system is useless without concrete things we've agreed on that fit int he system 20:40:45 for once 20:41:00 I mean - we already voted on thnis 20:41:02 this 20:41:09 how does #startvote work again 20:41:12 how many more times do we need to vote on voting on voting on things 20:41:13 I'm fine with test and iterate. If that's "slow" then that's okay. 20:41:14 Heh 20:41:14 #startvote 20:41:14 Unable to parse vote topic and options. 20:41:28 devananda: why do we need a tag system _before_ admitting new projects? new projects would join without the integrated-release tag, so they start at the bottom 20:41:32 ttx: http://ci.openstack.org/irc.html#voting 20:41:33 ttx, #startvote ? option1,option2,etc 20:41:37 #startvote Freezing or slowly considering ? freezing, slowly, abstain 20:41:38 Begin voting on: Freezing or slowly considering ? Valid vote options are freezing, slowly, abstain. 20:41:39 Vote using '#vote OPTION'. Only your last vote counts. 20:41:46 #vote slowly 20:41:47 slowly 20:41:48 #vote slowly 20:41:48 #vote freezing 20:41:51 #vote slowly 20:41:52 #vote slowly 20:41:52 Can't we just focus and start with a well defined base 20:41:52 #vote slowly 20:41:56 #vote slowly 20:41:56 #vote slowly 20:41:56 grr 20:41:59 #vote slowly 20:42:01 yay 20:42:07 30 more seconds 20:42:13 #vote abstain 20:42:31 ttx: you didn't have a rip off the bandaid option :) 20:42:34 * jbryce finds something funny about everyone “voting slowly” 20:42:37 #endvote 20:42:38 Voted on "Freezing or slowly considering ?" Results are 20:42:39 freezing (1): russellb 20:42:40 abstain (1): jgriffith 20:42:40 jbryce: :) 20:42:41 slowly (8): ttx, devananda, jeblair, sdague, mikal, mordred, dhellmann, markmcclain 20:42:45 jbryce: LOL 20:42:45 OK, let's proceed 20:42:56 I'd like us to spend some of the remaining time in the meeting to discuss the next addition in the pipe: 20:43:08 * Add OpenStackClient project (https://review.openstack.org/161885) 20:43:15 Last week we delayed final consideration of the Magnum addition to March 24 meeting 20:43:27 OpenStackClient is imho "an OpenStack project" and "one of us" 20:43:28 I'd suggest we set an application deadline, consider all projects who apply before the deadline as a batch, and then rip off the bandaid in one go 20:43:34 ttx: ++ 20:43:38 And being "officially part of OpenStack" might give it a nice contributors push 20:43:41 So I'm +1 on it 20:43:52