14:01:30 #startmeeting next-tags-wg 14:01:31 Meeting started Fri Jul 17 14:01:30 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:34 The meeting name has been set to 'next_tags_wg' 14:01:45 #link https://etherpad.openstack.org/p/next-tags-wg 14:02:30 OK, so for this first meeting I'd like to discuss a bit on the long-term goals, and then on a few short-term targets 14:02:38 sounds reasonable 14:02:39 anything you would like to discuss ? 14:03:00 Let's start with that and we can add more 14:03:14 #topic Long-term goals 14:03:52 I guess the main objective is to cover things that were covered before by integration requirements / integrated release meanings 14:04:05 +1 14:04:12 ttx: o/ 14:04:36 doesn't mean we should not also address nice-to-communicate things, but we should at least cover most of the things there 14:04:50 I tried to list those two sets on the etherpad, to varying degrees of success 14:05:15 As far as "facets of the integrated release" go, we are not that bad: 14:05:37 "Released together" and "managed release" is covered by release:* tags 14:05:43 I think some of the requirements on the checklist were sufficiently woolly that it would be ok for us to eliminate them from contention as tags quite quickly 14:05:54 there was an expectation of co-gating... not sure we can qualify that 14:06:06 sdague: ideas on this one ? 14:06:19 imho that one is out of date 14:06:21 yeh, I don't think we need to bring forward everything, we can reevaluate what's useful in bigtent world 14:06:27 hm ... we can certainly create "co-gating groups" and tag them ... but not sure that's useful anymore 14:06:33 agreed 14:06:37 but sdague full_stack_testing idea might be an equivalent 14:06:40 since the "single co-gate to rule the world" doesn't seem to be the thing anymore 14:06:50 ttx: I think co-gating is not really useful, that's why I proposed the full stack testing bit 14:06:57 ack 14:06:59 yeah full-stack testing is interesting 14:07:23 "Supported by OpenStack horizontal efforts" -> it's pretty much up for each team to come up with their *:suported variant 14:07:25 zaneb: yeh, I tried to walk out the real meaning of what was wrapped up in gate, and tempest, and just say "we build a cloud with our component and test it for real on every commit" 14:07:26 testcoverage:crap 14:07:27 heh 14:07:35 starter kit we covered 14:07:35 sdague: +1 14:07:51 stability I have a few suggestions we'll talk abvout 14:07:59 maturity is a bit harder 14:08:16 yeah, I don't think maturity can be a tag 14:08:17 for that one I'd like to see what the ops team comes up with in their data 14:08:29 yeh, maturity seems too nebulous 14:08:48 any missing "meaning" of the integrated release you'd like to add to list ? 14:09:26 if not we can skip to old graduation requirements 14:09:35 I assume the supported python thing is just going to be expressed by trove categorization in setup.cfg 14:09:39 which cover a few specific things 14:10:18 Do we agree that "absence of scope duplication" is no longer applicable ? 14:10:24 yes 14:10:45 next two are covered in the suggestions 14:10:45 yep 14:10:54 "diverse core reviewers team (more than 4 people)" 14:11:05 that one is interesting, since no team: tag has been proposing that at all 14:11:29 good to keep in mind that it was there, I don't think that's a top prio though 14:11:41 re: scope, our new project requirements mention it, and we've used it before when discussing applications, so i'm ok with how that covers my concerns 14:11:48 can't think of a tag there 14:11:51 (sorry i'm behind) 14:12:22 team tags are relatively low hanging fruit since we can script most of them against stackalytics 14:12:26 "enforce a minimum of 2 +2s before accepting a change" -- is that a current project team requirement ? 14:12:26 honestly, I think russellb's diverse team covers the basic points there, though I do think diverse danger needs to expose somewhere, as we've had a lot of 90%+ one org projects lately 14:12:48 if not, is it something of value for our users ? 14:13:00 I think our users probably don't care 14:13:16 and i like to think of "2 +2s" as a guideline, not a rule anyway 14:13:24 plenty of cases rubber stamping things in by 1 person is fine 14:13:24 ttx: that's _almost_ part of the 'are you one of us' test imho 14:13:26 that's cultural expectations and we enforce there instead 14:13:29 or cases where several +2s should be had 14:13:46 culture handles it well enough, agree 14:13:54 the rest are QA/Doc metrics imho and we'll likely redefine them, no need to go through them one by one... 14:13:59 (not disagreeing with russellb though, for the record) 14:14:06 unless there is one you want to discuss... 14:14:47 If not let's skip to short-term targets 14:14:55 history of triaging bugs/user support is probably not something we need tags for 14:15:03 might be better suited to the ops effort 14:15:10 whatever we're calling that 14:15:15 zaneb: yes, feels moere like a rating 14:15:21 exactly 14:15:22 "you suck at bug triaging" 14:15:44 ok, next tags then 14:15:51 #topic Short-term targets 14:16:15 One that was mentioned by several people are the integration tags, starting with devstack 14:16:29 sean / sdake proposed in_devstack and/or has_devstack_plugin 14:16:34 i can take on the team tags 14:16:42 I tend to be with zaneb, not sure the distinction is that valid 14:16:52 size, and "diversity danger" 14:16:57 sdague ttx you mean? 14:17:09 rather ttx do you mean sdague? 14:17:14 ttx: so the reason the distinction is valid, is that it actually is another thing the user would need to do 14:17:20 it was sdague and stevebaker iirc 14:17:27 sdague: get the plugin you mean? 14:17:29 ya not me, ok thanks bye guys :) 14:17:36 sdake: too many steves. as you were. 14:17:40 russellb: right, specify "enable_plugin" for that component 14:17:43 sdague: oh ETOOMANYSTEVES 14:17:48 sdake: ^ 14:17:52 roger 14:17:53 yeah, i guess so, not sure that's worth a tag 14:17:53 so my lean was to be specific about it 14:17:54 i'm off :) 14:18:02 more like a tiny section in the project's docs 14:18:16 but i don't have a strong opinion against it or anything 14:18:27 sure, we can always break it out later if people are confused by it 14:18:45 call it devstack_support 14:18:49 or something 14:18:52 yeah, trying to see if that piece of info is significant enough to justify learning another word 14:19:03 "works with devstack" is good info though 14:19:15 would have been a use case for attribute but I killed those last week :) 14:19:26 russellb++ 14:19:29 could also extend to "works with 14:19:39 sure, there are a bunch of projects that have random directories and copy instructions, those projects would not get that tag 14:19:42 "works with tripleo", "works with fuel", 14:19:52 so the model we come up with there is likely to be reused for horizon 14:19:57 because we really want everyone to do it in the documented way, so the user doesn't have to learn a massively manual thing 14:20:13 yeah devstack plugin is pretty easy to do 14:20:17 yep 14:20:21 i.e. we wouldn't distinguish between "has horizon support" built-in / as-plugin 14:20:52 I'm fine with that 14:20:58 does it matter if a thing is supported directly by (devstack|horizon|whatever) or the team itself provides the support? 14:21:21 ttx: my understanding from david-lyle is that Horizon doesn't want there to be two kinds of plugins long-term anyway 14:21:24 angle being about who provides the thing 14:21:48 zaneb: agree in-tree / plugin / module is more of an implementation detail 14:22:07 ttx: it is, until we figure out who supports what 14:22:21 should we have a common prefix for all those "supported in", "works with", "integrated with" things ? 14:22:37 my take on this is that I'd like all of the projects on that list to work toward eliminating that distinction over time, and separate tags just tends to reinforce that distinction 14:22:38 honestly, I don't feel too strongly either way, but it is worth figuring out if we are going to confuse folks 14:22:56 zaneb: eliminate what distinction? 14:23:00 i guess this does get into the idea of project relationships 14:23:08 sdague: between in-tree and out-of-tree plugins 14:23:18 which is actually interesting info 14:23:23 zaneb: there is a distinction on support 14:23:52 the reason for creating an out of tree plugin interface is the fact that we can't scale if every horiz effort has to own all the concept for the tent, so they provide a contract instead 14:24:20 sdague: oh, yeah, I'm not saying everyone should go to in-tree for everything 14:24:21 magnum has a devstack plugin, I'm not going to support that 14:24:34 I will support the contract that lets them do that 14:25:36 and the question is whether that's useful for our user community to get here 14:25:46 or if they figure that out via other means 14:25:47 sdague: I'm more saying that if e.g. Nova's DevStack plugin was also out-of-tree, you can be sure that somebody will make it super-easy to pull in out-of-tree plugins :) 14:26:02 so treat all plugins equal 14:26:06 it's quite easy today 14:26:21 but sort of an aside :) 14:26:23 zaneb: yeh, look at the interface today, we didn't need that to make it easy :) 14:26:56 sdague: well, as you said before, it's an extra step for the user 14:27:05 if everything is the same, there's no extra step 14:27:06 1-liner in local.conf ... enable_plugin networking-ovn http://git.openstack.org/openstack/networking-ovn 14:27:08 it's 1 line of config 14:27:11 that's just how you do it 14:27:38 right, the two things the distinction would communicate are: "who supports the integration" and "it may require an extra install step" 14:27:54 and I'm not just talking about devstack, I'd like this for all projects on that list 14:28:06 * russellb nods 14:28:06 but anyway, we're getting a bit off-topic 14:28:11 sure, though I guess we're wandering a bit 14:28:41 I guess the 'todo later' is probably an expectation on projects about what we'd expect out of them providing a plugin interface 14:28:42 we should ponder this a bit more ... not sure we've nailed an idea yet 14:28:52 I won't fight strongly either way. We could let the color decision to whoever goes and draft that one 14:29:00 I still think we need a common prefix those 14:29:03 for those* 14:29:16 but we can also bikeshed that common prefix name another day 14:29:27 yeah, I think it's a discussion for the TC 14:29:31 +1 for a common prefix 14:29:43 could we even propose all the tags in one review? 14:29:54 that would save a *lot* of time :) 14:30:05 We could, but in practice the smaller the change, the faster it gets in 14:30:07 I think coordinating the rest of the english would be a bit hard 14:30:24 I'll write up the devstack plugin thing on the plane to MN on Monday 14:30:29 ok 14:30:42 and people can hate on terms until we find something that works for people 14:30:44 #action sdague to draft *:*devstack* tag(s) 14:30:44 ok, so maybe start with a pilot and copy-paste once it has been wordsmithed to death? 14:31:24 Next category, team tags 14:31:40 We mentioned two in the brainstorming 14:31:55 One is team size, projects that are >60% developed by just one person (or 95% developed by just 2) are a bus factor risk 14:32:13 (your threshold may vary) 14:32:29 team:omnibus-proof 14:32:32 the other is the diversity-danger one, or Team monoculture 14:32:38 developed and/or reviewed by 14:32:56 So while I agree those are negatiuve tags, I think they provide value to our users as such 14:33:07 we are answering the "will the project be there tomorrow" question 14:33:11 I'd prefer we have tags for positive things 14:33:28 e.g. , collaboration, community 14:33:39 zaneb: sure, but I think the 100% one org thing is a challenge 14:33:46 vs. monoculture, , community 14:33:47 we're getting a lot of monoculture projects 14:33:52 zaneb: I feel like a "decent-diversity" tag is less of an answer than "danger-will-robinson-is-alone-coding" one 14:33:52 100% one org thing doesn't sound like openstack 14:33:59 :/ 14:34:16 lack of diversity in a young project is often expected 14:34:16 well, I think the monoculture bit is bad enough we want to call people on it 14:34:19 russellb: right, and I don't mind using a negative tag to call that long-term 14:34:20 sdague: totally agree there needs to be a separation between those first two levels 14:34:23 but in large established one, huge concern 14:34:35 russellb: yes, agree, so having the negative association with it is good 14:34:40 ok, here's my reasoning... 14:34:43 some times you also need sticks, not just carrots 14:34:43 it's something to fix 14:34:52 i prefer carrots though :) 14:34:58 *and* a useful bit of info for users 14:35:09 russellb: agree, sticks are hard to make coleslaw out of 14:35:12 it's hard to distinguish between 'doesn't have this tag' and 'nobody bothered to apply this tag' for users 14:35:13 lol 14:35:30 but let's get specific ... consider the fuel case vs. a project that just got launched by a few devs at 2 weeks ago 14:35:34 russellb: I agree we shouldn't have sticks for the sake of it, but if they provide an answer to users questions, then they are good tags 14:35:41 one of those deserves to be called out, the other maybe not 14:35:53 if there's no incentive for the team itself to come to the TC and ask for the tag to be applied, it could slip through the cracks 14:36:00 russellb: the other needs to know it needs to work on it though 14:36:04 i.e. requires vigilance on the part of the TC 14:36:05 ttx: true 14:36:16 zaneb: stuff like this are pretty automatic though 14:36:29 russellb already has a tool for the diverse team tag 14:36:30 positive tags offload the vigilance onto the teams that benefit 14:36:54 zaneb: but I think an absent tag is less of an incentive than the presence of a negative one 14:37:14 I also think it's fine that the TC has to be a bit vigilent in keeping an eye that projects are living up to what they said 14:37:31 sdague: fair 14:37:48 another option would be to just change the way we display them 14:38:06 I think tags should convey meaning, not absence of tags. Here we care if a team is diverse, or if it's a monoculture. We don't care if it's "moderately diverse" 14:38:07 i.e. no team tag -> big 'monoculture' banner 14:38:25 so we do a diverse and monoculture tag 14:38:35 not a "diverse" and "almost diverse" one 14:39:04 tags are affirmations. Trying to use combinations (AND / NOT / OR) wasn't a great success on the release:tags 14:39:10 "diverse" and "not-monoculture"? ;) 14:39:26 I'm relaxed, I don't think this is a big deal 14:39:30 just wanted to discuss it 14:39:30 we had to refactor them to be clearer affirmations 14:39:58 I feel on the team thing it's important enough to call it out as a bad thing, we really want all projects to end up diverse for long term health of our community. 14:40:03 russellb: I take it you will work on those ? 14:40:42 yep 14:40:45 (small-team and monocultural-team) 14:40:54 i'll start with team size, i think that's less controversial 14:41:02 OK, so you should draft those and will re-debate 14:41:05 we'll 14:41:05 and then the anti-diversity one 14:41:07 sdague: totally agree we should call it out somehow 14:41:08 yep 14:41:25 #action russellb to draft small-team and monocultural-team tags 14:41:58 Next category is a bit of a refactor 14:42:09 It's things that answer expectations 14:42:22 so timeline for deprecation of features / APIs 14:42:38 good stuff 14:42:42 forward-compatible config files 14:42:48 rolling upgrades 14:42:56 important technical bars we want projects to explicitly ACK that they meet 14:43:01 right 14:43:15 those are things projects opt to do 14:43:15 defining 'support' for rolling upgrades could be tricky? 14:43:20 contracts that they sign 14:43:24 zaneb: yep :) 14:43:31 obligations that they put onto themselves 14:43:46 so yeah, rolling upgrades is a slightly different duck there 14:44:03 zaneb: yeh, so I think that for something like that, a team says they do it, and we expect them to have a prominent document describing what that means 14:44:04 basically it gets into what kind of downtime is required for upgrades] 14:44:05 so we're saying that individual project teams will be responsible for assigning these tags to themselves (+1 btw) 14:44:08 ? 14:44:18 zaneb: +1, with a sanity check 14:44:29 hopefully with a pointer to a doc that explains it 14:44:38 and we read it over and say "yep, seems sane" 14:44:49 that sounds perfect to me 14:44:59 I think those will be the most useful things 14:45:00 russellb: I think pointer to doc is required for stuff like this, and should be part of what is in the tag description document 14:45:04 sdague: ++ 14:45:27 currently, good luck to tell what's the deprecation policy is for project Y 14:45:30 stuff like this is going to take time to get right on the tag proposal, it was the kind of stuff that I want to see, but was punting on :) 14:45:54 right, I think we'll do them one by one. I want to work on the deprecation policies, it's long overdue 14:45:59 yep, one at a time ... we'll build up a nice set over time 14:46:20 if someone wants to work in parallel on one of the others I'm cool with that 14:46:26 ttx: yeah, you had a nice write-up on API deprecation at one point that would be a good basis 14:46:32 in a thread a long time ago .. 14:46:36 about keystone v3 iirc 14:46:56 yeah, that one would likely be the middle policy 14:47:12 (between "never ever" and "f*ck you") 14:47:15 lol 14:47:22 "reasonable middle ground" 14:48:01 #action ttx to draft Deprecation policy contract tag 14:48:15 I can take the no-config-change one. that sounds simple enough 14:48:56 sounds good :) 14:48:58 zaneb: ideally it should describe how to do it right 14:49:12 so that people don't get to guess :) 14:49:21 OK, last but not least 14:49:22 QA tags 14:49:35 I'll let sdague detail fullstacktesting 14:49:36 I shall troll the ML for sdague's wisdom on that subject :) 14:49:43 zaneb: heh 14:49:45 er, trawl 14:50:04 My main question is whether we should bundle them or separate them 14:50:16 ttx: bundle which? 14:50:30 tag-per-testing-type vs. "well-tested" ? 14:50:33 i.e. qa:awesome or a bunch of qa:upgrade-tested, qa:unit-tested 14:50:36 right 14:50:54 qa:awesome runs us into the subjective space we were trying to avoid, right? 14:51:01 i.e. you could either describe a set of constraints or have a tag for each 14:51:22 honestly, upgrade-testing is only done by about 25% of our projects 14:51:27 qa:objective-gold-star 14:51:43 so I think being a separate tag is good 14:51:46 sdague: I don't think qa:awesome is more subjective 14:51:48 qa:upgrade-tested seems like a useful, objective tag 14:51:58 because, honestly, some projects might not feel they need it 14:52:06 their community is young, and people are fine without it 14:52:21 full-stack-testing, same thing 14:52:23 if QA:A means your QA does A and QA:B means your QA does B... qa:awesome would just mean your QA does A and B 14:52:34 it could 14:52:40 sdague: and that's ok, as long as it is explicit to users 14:52:40 but tags are cheap, right? 14:52:44 i.e. you would describe what is needed to get the QA:awesome label 14:52:46 zaneb: right, exactly 14:53:04 sdague: sure. the question is more, what user question does it answer ? 14:53:08 I think that was the biggest issue on the old integration requirements and the angst we saw 14:53:29 because the requirements were one size fits all, but the project landscape is diverse 14:53:59 sdague: ok, if you think there is no such thing as an overall "QA" state no point in bundling them 14:54:03 ttx: it answers "can I expect a smooth upgrade without manual intervention" 14:54:03 I agree (I think) with sdague, create the individual tags and users can decide for themselves whether that is awesome or not 14:54:29 (i.e. we are not answering "does this project have good QA". We answer more specific questions 14:55:06 honestly, if people want to bundle later, I think that's fine, but lets start with specifics 14:55:24 sdague: ok, you had me at "some projects might not feel they need it" 14:55:35 means you can't define QA in one dimension 14:56:15 yeh 14:56:16 Do you plan to draft one of those ? 14:56:28 not anytime soon 14:56:35 ok, so up for grabs 14:56:42 We already have at least one each on our plates 14:56:46 yes, happy to review anyone that wants to run with it 14:57:14 https://github.com/openstack-dev/grenade/blob/master/README.rst#theory-of-upgrade is some reasonable starter points for it 14:57:26 #topic Open discussion 14:57:45 ttx: thanks for organizing ttx :) 14:57:57 so, my only open question, how do we get more folks contributing here :) 14:58:14 I used to want "theme:" tags so that people using a project navigation website would find Manila once they found Cinder 14:58:16 because it's currently tc members, + zaneb (who is in most tc meetings anyway), and I was hoping we'd fan out more 14:58:28 hopefully the more work we do, the more apparent the value becomes, and the more people that will want to push forward 14:58:31 but now I think that info should come from another source and be exposed on the same website 14:58:37 sdague: I think we had one more volunteer who couldn't make it this week 14:58:42 zaneb: ok 14:59:05 ttx: so, it's probably worth putting together a backlog of "things we'd find useful, no one working on them" 14:59:19 so that if someone wanted to contribute, they'd have a pile to pick from 14:59:27 sdague: honestly I have been just reading through and just trying to catch up with the intentions 14:59:30 good idea 14:59:41 I guess the 'Next tags' list in the etherpad is that for now 14:59:42 Maybe build on top of the "next tags" section of the etherpad ? 14:59:57 yeh, with any relevant details 15:00:12 maybe we can add a couple more 15:00:24 ML posts, links to stuff that would be useful to define that thing, etc 15:00:42 because if it's just a name, it will be too opaque 15:01:34 OK, let's build from that 15:01:35 sdague: also "because it's currently tc members, + zaneb (who is in most tc meetings anyway)" might make it slightly intimidating for some to step out ;) 15:01:39 Time is out 15:01:55 thanks ttx et al 15:01:58 jokke_: ++ 15:02:03 thanks all, this has been productive I think 15:02:11 I should post something about that meeting, early next week 15:02:27 #endmeeting