20:02:44 #startmeeting tc 20:02:45 Meeting started Tue Aug 18 20:02:44 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:48 The meeting name has been set to 'tc' 20:02:52 Our agenda for today: 20:02:57 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:03 #topic Using topics to classify governance changes 20:03:15 3 weeks ago sdague asked that we use Gerrit topics to mark governance changes that do not actually require formal votes 20:03:21 so that we can filter them 20:03:30 I sent an email to the -tc list proposing to do the reverse (mark those who actually require formal votes), since there are lots of corner cases: 20:03:37 #link http://lists.openstack.org/pipermail/openstack-tc/2015-July/001005.html 20:03:45 No answer to that proposal... yet 20:03:51 seemed reasonable to me 20:03:53 not sure that means "go ahead" 20:03:57 I think we silently agreed 20:03:57 russellb: ok 20:03:58 yeah 20:04:00 i didn't have anything to add 20:04:09 so yeah, my silence was +1 :) 20:04:09 extreme lazy consensus 20:04:24 #action ttx to mark things that we actually need to vote on, for easier filtering 20:04:30 yeah, mark the subset -- the point was to just be able to filter 20:04:38 just hoping that doesn't mean nobody will pay any attention to other changes 20:04:54 i'll still have all changes hitting my inbox personally 20:04:55 o/ 20:04:55 it'll help me prioritize 20:05:00 a search filter sounds great 20:05:01 * dhellmann subscribes to all 20:05:13 #topic Add and apply tag team:size-large 20:05:14 I could add it to the TC dashboard query, too 20:05:14 * flaper87 uses gertty 20:05:20 YEs, I'm one of those 20:05:25 so this tag came up in the next tags WG 20:05:28 or rather, this family of tags 20:05:30 * jeblair high-fives flaper87 20:05:33 #link https://review.openstack.org/208029 20:05:35 the idea of tagging info around team sizes 20:05:36 #link https://review.openstack.org/208030 20:05:42 In the discussion emerged the need for a team:very-small tag, which is what consumers of that data are actually looking for 20:05:56 "Is a project maintained by enough people to be there tomorrow" (same as diverse-affiliation) 20:05:56 jeblair: :D 20:06:06 right, happy to propose "very-small" as a red flag tag 20:06:08 That said, that doesn't mean a team:very-large tag isn't useful, to distinguish projects with a giant group behind them... 20:06:17 russellb: I guess that still answers a question people might have ? 20:06:18 curious if anyone else finds "very-large" useful 20:06:25 it seems somewhat interesting to me 20:06:33 mmh, have we considered using number-ranges ? 20:06:35 but is it just interesting, or is it useful? 20:06:37 * russellb shrugs 20:06:38 throwing it out there 20:06:40 I think that activity-level:high is more accurate for this? 20:06:41 Yeah, I can see how *I* would use iut, not sure about others though 20:06:47 rather than small/very-small/big 20:06:47 russellb: so it is intended to be different than "diverse"? 20:06:50 annegentle: ++ 20:06:57 jgriffith: yes 20:07:02 flaper87: "medium" doesn't answer any question 20:07:03 not trying to paint a bike shed, but it seems like this isn't about team size but activity / scope 20:07:05 jgriffith: diversity vs # of people doing the work 20:07:07 At least we know how many we're talking about (not sure if that makes sense) 20:07:17 russellb: thanks 20:07:26 is a diverse group of 5? or is it a diverse group of 50? 20:07:41 doesn 20:07:51 russellb: yeah, I see the difference now. Thank you 20:07:53 it's about warning for potential problems, no? 20:07:54 annegentle: it's arguably az comabo. One very active person is certainly more fragile than 3 moderately-active persons 20:08:04 az comabo ? 20:08:06 ttx: agreed, which is why I'm wondering if we've considered rage numbers 20:08:08 what am I typing 20:08:17 "a combo". 20:08:17 rage numbers? sounds fun 20:08:27 flaper87: do you mean drive-by fixes? 20:08:32 also, the necessary team size may vary by project moreso than diversity 20:08:39 <=10, <= 20, >20 20:08:41 also maturity 20:08:43 jeblair: fair 20:08:53 a mature specialised thing needs many less changes 20:09:03 is there some # that's "very-small" / "too-small" regardless of project? 20:09:06 flaper87: I don't think <=20 answers any question anyone has 20:09:15 if not, then maybe the whole tag category should be dropped 20:09:28 also the 6 commits and 30 reviews, is that a known ratio from a given team? 20:09:33 ttx: what does very-small say? What do we base that on? 20:09:42 I feel like people want to know if "enough" people support their project. They may want to know if the project is giganormous, but I'm not sure of that 20:09:45 annegentle: completely arbitrary starting point 20:09:52 flaper87: bus factor 20:09:52 russellb: ok 20:10:17 flaper87: A project with only one active person is extremely fragile. 20:10:19 i picked those numbers out of the air, and they seemed to capture the biggest handful of projects 20:10:20 yeah.. I think small is more of a concern 20:10:23 there are some of those in openstack today. 20:10:29 I ran these numbers for docs, and only one specialty areas will be above that ratio I think... will have to double check 20:10:37 I think people should know about them. 20:10:38 ttx: sure, doesn't <= 10 same the same thing? 20:10:49 <= 10 what? 20:10:52 my point is, we gotta get those "quantifications" from somewhere 20:10:58 also curious how to aggregate that across all the repos for all the deliverables in a project, assuming it's based on core review/approver group membership or commit activity or... 20:11:08 ttx: whatever very-small is made of, I guess 20:11:18 fungi: the union of all activity in all repos for a team 20:11:20 is how it works right now 20:11:22 If they're not large they're small(ish) :) 20:11:26 russellb: thanks 20:11:28 flaper87: russellb uses "'active contributors" as a metric 20:11:42 I thiknk under 3 the project is at risk at that should be communicated. 20:12:08 so if nothing else, seems to be agreement that "very small" is the most valuable thing 20:12:14 so as a next step i'll propose that 20:12:19 yeah, maybe we shjould start with this one 20:12:23 and then once we work through that, we can revisit "large" (maybe) 20:12:33 I blame philosophers and their wine for all the typos I make today 20:12:38 * flaper87 goes to os-zaqar and starts counting ppl 20:12:42 20:12:48 my gut says highly active could be valuable, to set expectations for review time perhaps, but won't tell much to people who use or operate a service 20:12:51 flaper87: script is already merged iirc 20:12:55 russellb: very large might be an indication that the project may move pretty slowly, too, so it could be useful 20:13:04 dhellmann: right, my thinking also 20:13:06 russellb: damn :P 20:13:15 review tie is actually something we _can_ measure, if that's a useful metric to build a tag around 20:13:19 er, review time 20:13:24 fungi: that sounds interesting 20:13:29 dhellmann: In all cases we need to define the question before we define the tag that would help answer it 20:13:31 already measuring that with bitgeria 20:13:48 ttx: sure, and measuring review time directly is likely better 20:13:50 not sure how easy it would be to get that data on demand 20:13:56 In the current case, the question is "is the project supported by enough people that it will survive individual accidents 20:14:08 like people burning out 20:14:09 #link http://activity.openstack.org/dash/browser/ 20:14:29 and also reviewstats data, and similar data to that in stackalytics 20:14:35 ok, I think I see the point of using very-small rather than numbers 20:14:38 sorry, took me a bit 20:14:39 :D 20:14:43 I feel like if you have less than 5 the project would seriously suffer if they lost one person. 20:14:46 * flaper87 is slow today, ask everyone 20:14:50 ttx: +1 20:15:04 suffer to the point where there could be cascading failure. 20:15:05 ttx: I can say, from my own experience, that's true 20:15:08 :) 20:15:14 that is the risk I want the tag to communicate 20:15:15 <=2 is an obvious low limit, because then your cores can't submit code. :) 20:15:25 dougwig: ha 20:15:31 doesn't mean people won't use the project. Just helps them make their own idea 20:15:39 dougwig: been there too :P 20:15:41 for very small team sizes, it's convention to just self-approve or single-core approve changes 20:15:52 flaper87: still there (fwaas and vpnaas). 20:15:58 dougwig: :( 20:15:59 so they're not _exactly_ blocked on submitting changes to merge 20:16:20 there is a component of diversity within low numbers... a team of10 people and 8 work for same company is at serious risk of collapse too if company changes direction.. should probably be considered small 20:16:21 when we say project here 20:16:23 dougwig: those imply it might be valuable to call this out on a per-repo basis 20:16:30 do we mean 'code tree' or 'group of people' ? 20:16:30 anyway, I think Russell has a way forward 20:16:34 this tag right now is focused on teams, so it'd be Neutron overall 20:16:39 lifeless: project team 20:16:56 things like openstack/requirements have ill-defined teams IME 20:16:57 anyway, yes, i have a way forward 20:17:01 although it doesn't have to be a team tag I guess 20:17:09 ttx: could it be a tag team? 20:17:22 or a tag team tag ? 20:17:35 team tag� ? 20:17:44 tagception 20:17:47 +1 for squared 20:17:50 * flaper87 rofl 20:17:52 i think we should move on 20:18:05 wow squared 20:18:08 * annegentle is impressed 20:18:12 russellb: agree on calling out per team somehow (where team may be a larger project subteam). sorry for delay, at ops meetup. 20:18:37 keeping in mind that the tc abandoned the concept of per-repo tags, so i don't see how doing it on a per-repo basis would be feasible 20:18:38 dougwig: all good, glad you're there! would love to hear your feedback after 20:18:55 fungi: yar 20:18:57 russellb: it's true that it could be an per-repo tag. After all some of the neutron circus things might be supported by only one person 20:19:23 ttx: but someone could make the same argument about components of a project in a single repo 20:19:26 so not sure we need to worry too muhc 20:19:39 seems like at a minimum you'd need to aggregate across all repos for a given deliverable 20:19:40 you'll come up with something :) 20:19:42 we're not going to capture "maintainers of a feature in a project" at this level 20:19:43 yup 20:19:44 Let's move on 20:19:58 #topic Add new openstack kiloeyes repository 20:19:59 fungi: ++ 20:20:01 #link https://review.openstack.org/210175 20:20:13 Summary of the feedback is that this is pretty new, so it's way too early to be considered "one of us" 20:20:27 It also shows that competition between openstack projects is fine, but only as long as the alternative provides a different value proposition *and* collaboration is not an option 20:20:40 here it seems avenues for collaboration have not been explored yet, and the value proposition is unclear 20:20:59 fwiw, I'm not at all concerned that the API is the same. Compatibility is a feature. 20:21:03 so I think asking for it to live a bit in stackforge is not too much too ask 20:21:16 dhellmann: agreed 20:21:21 stackforge is going away 20:21:24 ttx: except ya ^ 20:21:29 lifeless: no it's not. 20:21:29 no its not 20:21:31 the name is, but not the concept 20:21:39 arg 20:21:53 can we please pick a new name for the concept then ? 20:21:59 it's just living in the same git prefix for convenience 20:21:59 this project can live as an unofficial project 20:22:05 "unofficial" 20:22:19 I stand corrected 20:22:42 sure, that won't make my brains leak out my ears :) 20:22:56 anyone disagreeing with that outcome at this stage ? 20:23:03 nope 20:23:08 tentforge? 20:23:12 (asking them to live a bit before applying for official projetc team ?) 20:23:15 edleafe: lol 20:23:19 not me, I hope Tong li will also come back with some answers to my qeustions 20:23:20 project can live in any github org it wants to, and observe the OpenStack way, do we need to give them a timeline? 20:23:42 s/not me/no objections from me/ 20:23:45 flaper87: agreed. I'm not going to gang up on the review, but I had almost identical questions as mordred 20:23:57 jaypipes: yeah, me too 20:23:58 I like to see a project exist for at least 3 months (and/or doing an initial release) before evaluating if they behave like an openstack project 20:24:05 annegentle: I think we want to see what happens and let them come back 20:24:10 ttx: initial release might be good 20:24:11 (different for horizontal teams) 20:24:17 deliverable maybe? 20:24:27 dhellmann: sounds good 20:24:37 ok, I'll write up somthing on the review 20:24:48 I don't just want to see what happens, I want to make sure the get the right guidance too 20:25:02 #action ttx to close the kiloeyes request by directing them to unofficial/stackforge space for the time being 20:25:18 Moving on... 20:25:21 flaper87: yeah, "talk with monasca and see what comes of that" sounds really good 20:25:37 #topic Deprecation policy tags 20:25:39 jeblair: ++ 20:25:49 First part 20:25:51 #link https://review.openstack.org/207467 20:25:55 So I updated this to match N+2 deprecation, as several of you requested. I had two questions left 20:26:03 First question is do we really want to describe a "never deprecate, always support" model 20:26:14 I kind of went back-and-forth on this one, and I tend to think now that saying you won't ever change is not really honest anyway, so the value of asserting that is limited 20:26:16 "never" is a long time 20:26:22 i don't think it's honest 20:26:25 agreed 20:26:27 There is more value in describing a "common deprecation policy" which sets a minimal standard and then ask projects if they want to assert that they follow (at least) that level 20:26:35 Set a baseline, basically 20:26:42 ++ 20:26:45 ++ 20:26:51 ++ 20:26:58 ++ 20:27:00 OK, so I'll amend the proposal to remove the "never say never" one 20:27:21 yep 20:27:31 #action ttx to amend 207467 to remove will-support-everything-forever variant 20:27:37 Second question is... should we (the TC) top-down define what we mean by "deprecation policy baseline" and ask projects to assert if they will follow it... or should we somehow open the definition for ML consensus 20:27:46 does *any* openstack project gurantee forever? 20:27:47 One part of me thinks that we should open the discussion, another part of me thinks this needs to be opinionated and not be the lowest common denominator 20:27:56 lifeless: I heard Swift claim that 20:28:09 lifeless: I could see it being valuable for CERN and object storage 20:28:10 ttx: personally I prefer opinionated and just have it 20:28:15 notmyname: ^ 20:28:15 ttx: we have an established community standard here, so I think it's reasonable to start with that. If projects want to propose other models, that is also reasonable. 20:28:15 ttx: I do have a question about the migration requirement... would an acceptable answer be something is deprecated and has no migration? 20:28:17 sometimes in the past. They might have been drunk though 20:28:32 ttx: I think there's good representation of the projects here on the TC to justify that 20:28:41 i don't think the N+2 is least common demoninator, it's a reasonable common policy 20:28:47 seems like a good place to start 20:29:01 markmcclain: I think you need to provide a way out 20:29:15 That's what we've been following somehow 20:29:28 or at least tried to follow to the best of our capacities 20:29:29 flaper87: +1 20:29:32 right but what if we support a feature that just does not make sense in the future? 20:29:33 not necessarily a migration tool or anything. Then you need to survey your users and see how much time they need to implement that migration 20:29:44 flaper87: at least it's been our minimum 20:29:53 flaper87: reality has been a different story :( 20:29:57 so, lets be opinionated here since N+2 has proven to be a good policy so far 20:29:59 jgriffith: yeah 20:30:01 :( 20:30:14 markmcclain: migration can be "that feature was stupid, so you should stop using it" but then survey needs to confirm that everyone agrees it was stupid 20:30:24 and the community is not strange to the concept and policy 20:30:30 could be more... shouldn't be less 20:30:41 * flaper87 should write longer messages rather than using IRC as if it were whatsapp 20:30:53 markmcclain: so I guess the answer to your question is "it depends" 20:31:06 jgriffith: +1 20:31:14 ttx: ok.. as long as that option should available... concerned that if we require even a minimum migration we never be able to get rid things many would consider mistakes 20:31:33 opinionated++ 20:31:43 markmcclain: I think what we require is discussion of the proposed migration with the users 20:31:55 makes sense 20:31:58 even if "proposed migration" =~ "stop using it" 20:32:31 Let's move to the second change here: config option deprecation policies 20:32:35 #link https://review.openstack.org/207584 20:32:43 we have two options: we can track it separately from API/feature deprecation policy assertion 20:32:50 or we can amend the API/feature tag to make clear config options are part of the user-visible stuff that is covered 20:33:04 ttx: merge them! 20:33:05 Personally I think the latter makes more sense and is less confusing. I just don't picture a project would have one but not the other 20:33:17 +which 20:33:23 well 20:33:34 I can see placing a different standard of burden on users and operators 20:33:39 or rather, not sure we need that granularity 20:33:46 To me, by default, everything the user can interact with should follow the same deprecation path. There may be exceptions, sure, but... 20:33:50 operator churn doesn't affect workload portability, for instance 20:33:55 lifeless: that's a good point 20:34:23 I think api compat is much more "watched" by users but that may be from where I sit maintaining API docs 20:34:30 so it's more operator-visible features deprecation and users-visible feature deprecation ? 20:34:43 annegentle: no really, just different users. 20:34:56 I see a separation myself -- each user type has different expectations 20:35:07 When it comes to deprecating things, I prefer to consider everyone as users 20:35:15 without any separation 20:35:23 flaper87: yeah, I lean towards that too 20:35:28 flaper87: I suppose so, you can avoid consternation for all parties then 20:35:28 ttx: I would assert so yes. Its entirely possible we'll treat everyone the same in future, but that hasn't been the case so far 20:35:49 honestly APIs that are extensible are at the mercy of provider decisions anyway 20:36:13 who is with flaper87, who is with lifeless ? 20:36:14 so, same deprecation everywhere 20:36:23 flaper87 flaper87 flaper87 flaper87 20:36:24 annegentle is with flaper87 20:36:25 * flaper87 stops that 20:36:31 I don't think our tags should be aspirational :) 20:36:35 do we actually anticipate different policies at this point? 20:36:42 they should be reflecting useful differences we already have 20:36:53 dhellmann: currently we expect all ex-integrated projects to assert both 20:37:08 since it was an unofficial rule for them anyway 20:37:09 ttx: i mean would the timelines be different 20:37:16 right 20:37:17 dhellmann: I was thinking of microversions versus nova.conf 20:37:23 nova API deprecations are yyyyears long 20:37:26 393355 20:37:29 nova.conf deprecations are cycles long 20:37:48 russellb: 11007663 20:37:56 :) 20:38:02 lifeless: many times is because people simply forget to remove deprecated things 20:38:09 but I don't know about nova 20:38:13 :P 20:38:29 due to their nature, assertions are a bit difficult to tweak once they are defined (you have to confirm any mod with all the projects that asserted the tag, so I'd prefer to get them right 20:38:32 lifeless: could we agree to put both of those timelines in one tag? 20:39:33 I think it's fine to have them both in a single tag. If we need to split it in the future that's easier than the other way around 20:39:43 sure 20:39:48 yep 20:40:01 If we realize there is need to track/communicate something more... granular, we can split it then 20:40:16 but I'll make sure I talk about operator-facing and enduser-facing stuff 20:40:23 in whatever language I come up with 20:40:35 so that it's clear that the tag currently asserts both 20:40:42 mmh, I'm still not convinced we should separate them from a deprecation perspective 20:40:49 I guess I'll comment on the review 20:40:50 flaper87: we aren't 20:40:55 oh ok 20:40:59 I was confuised by your comment 20:41:03 sorry 20:41:17 confused, even 20:41:26 Alright, I'll take care of the big merging 20:41:34 next topic 20:41:40 #topic Adds and apply guidelines for project and service names 20:41:42 #link https://review.openstack.org/201160 20:41:45 #link https://review.openstack.org/201670 20:41:49 annegentle: are we making progress or is it just a neverending circle of rebases ? 20:42:20 annegentle: I left a "-1 I have a question, I'm sorry it shouldn't be -1 please don't hate me" comment 20:42:32 ttx: Had a breakthrough this week; keep Block Storage 20:42:41 ttx: so the updates have been to support initial caps 20:42:54 ttx: I sense this is where most people want naming to land 20:42:58 flaper87: no worries 20:43:13 "Block Storage service" ? 20:43:25 ttx: check 20:43:26 annegentle: we should talk about auto-generating expansion macros for sphinx from the projects.yaml file 20:43:43 expansion macros? 20:44:13 702487 20:44:17 722228 20:44:28 dangit 20:44:41 flaper87: so kiloeyes could be the metric measurement I spose... I don't think release names are "reserved" 20:44:42 russellb turned into a WWII number station 20:44:48 * dhellmann thinks russellb is multi-tasking 20:44:49 flaper87: I honestly didn't make the connection for a bit 20:45:10 annegentle: I did, to be honest. When dhellmann mentioned I was like "So, I was not the only one" 20:45:21 annegentle: but I see your point 20:45:32 I'm sorry, I can't read kiloeyes and not think of the 5-eyes spy network... if thats deliberate its most unfortunate 20:46:28 flaper87: That said, I wonder if we should talk about "reserved words that cannot go into a service name such as copyrighted names?" 20:46:41 annegentle: so.. you have all you need to make progress ? 20:46:42 does the list of "don't do" belong in the guidelines? 20:46:47 ttx: I think so 20:47:00 can a name be copyrighted? 20:47:22 annegentle: I believe that list should be there 20:47:23 lifeless: um did I verb a noun? 20:47:25 IANAL but I don't think so. 20:47:36 if anything, it'll help us to review names properly 20:47:51 annegentle: I think you hopped intellectual property tracks :) 20:48:00 lifeless: right 20:48:11 flaper87: yeah, and the point of the guidelines is for reviewing 20:48:27 lifeless: was thinking of the Chef/Puppet permissions 20:48:48 other questions on that one ? 20:49:51 I guess not 20:49:54 #topic Workgroup reports 20:49:58 * Project team guide 20:50:03 I approved the initial version for the missing chapter, so the initial version of the guide is now complete 20:50:09 We just need to publish it. 20:50:11 that means i need to publish it 20:50:13 ttx: danke and sorry for the dely 20:50:18 jeblair: indeed 20:50:23 jeblair: <.< 20:50:32 * jeblair stops hiding behind flaper87 20:50:43 HA! I knew you were there 20:50:53 nice!! Way to go. 20:50:58 that's really impressive 20:51:23 for the curious ones, let me get a URL 20:51:40 http://docs-draft.openstack.org/67/194567/3/gate/gate-project-team-guide-docs/7a3af25//doc/build/html/ 20:51:58 (that's the gate build for the latest merge) 20:52:01 dhellmann: ttx yubikey nano. convenient, except easy to hit when moving laptop around 20:52:37 emulates a keyboard, types one-time passwords into your irc client ;) 20:52:41 jeblair: any idea when you can work on that ? Or should someone else take the job ? 20:52:54 ttx: can do this week. 20:52:58 awesome 20:53:02 * Comms 20:53:04 annegentle, flaper87: o/ 20:53:11 'sup ? 20:53:12 holla 20:53:23 fungi: yeah.. 20:53:37 annegentle, flaper87 not sure we need another post right now 20:53:38 I got a blog post out, late, last 2 week intervals. 20:53:40 #link http://www.openstack.org/blog/2015/08/technical-committee-highlights-august-11-2015/ 20:53:48 I've been lacking in the last couple of weeks. annegentle, sorry about that. 20:53:50 two 2-week intervals 20:53:53 given that we didn't have a meeting last week and this week(s is very transitional 20:53:53 flaper87: no worries 20:53:58 ttx: agreed 20:54:07 * Next tags 20:54:09 keep getting input on whether those are useful 20:54:12 We still are processing the first wave of new tags, so no new things here 20:54:27 * Other 20:54:37 Two weeks ago we discussed two areas of focus for the rest of the cycle: making progress on the service catalog, and improving cross-project discussion in general 20:54:46 * flaper87 loves ttx's quote on that post 20:54:48 How should we make that happen ? Should we form *other* workgroups that would meet outside of the weekly TC meeting ? 20:54:51 flaper87: :) 20:55:06 * ttx needs to work on the successbot 20:55:16 An IRC bot to celebrate little successes 20:55:24