21:01:38 <johnthetubaguy> #startmeeting crossproject
21:01:39 <openstack> Meeting started Tue Sep  8 21:01:38 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:43 <openstack> The meeting name has been set to 'crossproject'
21:01:47 <johnthetubaguy> courtesy ping for david-lyle flaper87 dims dtroyer johnthetubaguy rakhmerov
21:01:48 <johnthetubaguy> courtesy ping for smelikyan morganfainberg adrian_otto bswartz slagle
21:01:48 <johnthetubaguy> courtesy ping for adrian_otto sdake kiall jeblair thinrichs stevebaker j^2
21:01:49 <johnthetubaguy> courtesy ping for docaedo mestery Daisy zigo Piet notmyname ttx mtreinish
21:01:50 <johnthetubaguy> courtesy ping for isviridov gordc SlickNik cloudnull catherineD loquacities
21:01:51 <johnthetubaguy> courtesy ping for thingee hyakuhei redrobot dirk TravT vipul emilienm
21:01:52 <johnthetubaguy> courtesy ping for SergeyLukjanov devananda boris-42 nikhil_k
21:01:53 <notmyname> here
21:01:55 <lifeless> ALL THE PINGS
21:01:56 <gordc> o/
21:01:57 <EmilienM> o/
21:01:59 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
21:01:59 <SheenaG> o/
21:01:59 <mestery> o/
21:02:00 <lifeless> johnthetubaguy: you missed me :)
21:02:03 <elmiko> o/
21:02:06 <stevebaker> \o
21:02:07 <edleafe-> o/
21:02:08 <Piet> here
21:02:09 <bknudson> people don't have alarms?
21:02:16 <dims__> o/
21:02:19 <johnthetubaguy> lifeless: the tool missed you off, odd
21:02:34 * rockyg waves from the back
21:02:36 <EmilienM> lifeless: we always miss you, you must be absent from previous logs ;-)
21:02:45 <lifeless> EmilienM: nope, I've been here many times
21:02:46 <bknudson> we need an infra job for this.
21:02:54 <docaedo> o/
21:02:58 <jungleboyj> o/
21:02:59 <sdake> o/
21:02:59 <bknudson> bot should handle it
21:03:13 <mordred> bknudson: could we write an infra job that can write the infra jobs we need?
21:03:14 <jokke_> o/
21:03:22 <johnthetubaguy> I use a script, so its almost there
21:03:30 <johnthetubaguy> well use the script
21:03:33 <johnthetubaguy> anyways
21:03:46 <johnthetubaguy> #topic Review past action items
21:03:56 <johnthetubaguy> dims to ping some nova cores about https://review.openstack.org/#/c/205931/ (change now approved)
21:03:57 <philipw> o/o
21:04:16 <johnthetubaguy> well merged actually
21:04:22 <johnthetubaguy> shamail barrett1 to share the link and people will let us know if they disagree with the current "prioritized" user story list.
21:04:28 <johnthetubaguy> not sure if I saw that on the ML?
21:04:48 <johnthetubaguy> but I did see #link http://specs.openstack.org/openstack/openstack-user-stories/
21:05:03 <johnthetubaguy> the chair rotation list is full, so thats all good
21:05:04 * jroll a couple minutes late, oops
21:05:15 <johnthetubaguy> #topic Team announcements (horizontal, vertical, diagonal)
21:05:24 <ttx> On the release management front
21:05:29 <ttx> We tagged liberty-3 last week, we are now in:
21:05:40 <ttx> * FeatureFreeze (features, new config options, database schema changes need exception to merge)
21:05:45 <bknudson> yeah!
21:05:46 <ttx> * DepFreeze (addition of new dependencies or 3rd-party dependency bumps need exception to merge)
21:05:53 <ttx> * StringFreeze (resist changing strings to facilitate the work of docs and I18N)
21:05:54 <jungleboyj> Yay!
21:06:02 <ttx> We also need to cut liberty release branches ("stable/liberty") for libraries asap
21:06:11 <ttx> That means you should make releases for recent client features if you haven't already... and we should cut the branches from there
21:06:15 <bknudson> cap em!
21:06:15 <jokke_> \\o \o/ o// o/7
21:06:21 <ttx> That doesn't mean it's the last liberty release for clients, you can still do bugfix releases if needed
21:06:28 <ttx> But all features should be there
21:06:32 <ttx> dhellmann sent a reminder:
21:06:36 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/073686.html
21:06:38 <johnthetubaguy> ttx: do you need the libs to help with the stable branch cutting, or are you just going to use the last tag?
21:06:40 <stevebaker> I haven't seen a novaclient release for a while
21:06:57 <ttx> johnthetubaguy: I'll be using the last tag
21:07:12 <zigo> o/
21:07:16 <johnthetubaguy> ttx: cool
21:07:23 <ttx> but that means you better do a tag if you want the current features in master to be used in the liberty line of the client
21:07:39 <ttx> otherwise that will make for a lot of backporting and exception fun
21:07:47 <johnthetubaguy> ttx +1
21:07:56 <jokke_> ttx: when are you going to cut the branches? Tomorrow, by end of the week, something else?
21:08:09 <ttx> see that thread I just linked to, dhellmann explained in much more eloquent wording than me
21:08:18 <ttx> jokke_: end of week at this stage
21:08:27 <jokke_> thnx
21:08:36 <ttx> we are a bit behind schedule
21:08:50 <jokke_> we try to get patch rel of glanceclient out before that then to avoid ton of backporting
21:08:53 <zigo> If possible, it'd be nice to have oslo.FOO libs completely frozen a bit earlier than last cycle.
21:09:12 <zigo> Otherwise, it's quite difficult to do enough testing of packages (ie: too much update work to be done...)
21:09:13 <ttx> zigo: yeah, as I said we are a bit behind
21:09:29 <dims__> zigo: oslo.FOO with latest g-r is out this morning
21:09:39 <ttx> oslo should be done now
21:09:53 <ttx> anyway, that's all I had
21:09:59 <ttx> questions?
21:10:00 <mtreinish> I actually have something for this topic this week
21:10:09 <ttx> mtreinish: ooooh
21:10:11 <fungi> the vmt coverage criteria are basically solidified after our -dev ml thread so i'll follow up with the governance addition in the next day or so
21:10:16 <johnthetubaguy> mtreinish: sounds good
21:10:28 <mtreinish> the tempest plugin interface is all ready to go now
21:10:45 <mestery> mtreinish: Coolio!
21:10:48 <mtreinish> manila started a gating job using tests via the plugin interface last week
21:10:58 <mtreinish> and I pushed a tag to tempest to signify it's stability
21:11:10 <bknudson> do you want all projects using plugins?
21:11:12 <mtreinish> so project can go and add external test suites and have them act like part of tempest
21:11:12 <bknudson> e.g., keystone
21:11:30 <mtreinish> bknudson: keystone support is in the tempest tree
21:11:37 <gordc> mtreinish: you have review handy just for reference?
21:11:37 <mtreinish> I'd rather see tests contributed to tempest for that
21:11:46 <mtreinish> gordc: for the manila plugin usage?
21:11:54 <gordc> mtreinish: yep
21:12:00 <mtreinish> gordc: sure one sec
21:12:22 <mtreinish> gordc: https://review.openstack.org/201955
21:12:37 <mtreinish> gordc: also: http://docs.openstack.org/developer/tempest/plugin.html
21:12:47 <gordc> mtreinish: awesome. thanks very much!
21:12:51 <johnthetubaguy> #link http://docs.openstack.org/developer/tempest/plugin.html
21:13:23 <johnthetubaguy> cool, any more for any more?
21:13:40 <mtreinish> bknudson: fwiw, I have the list of what's supposed to be in the tempest tree here: https://wiki.openstack.org/wiki/QA/Tempest-test-removal#Tempest_Scope
21:13:57 <bknudson> so keystoneclient ?
21:14:17 <mtreinish> bknudson: keystone client has it's own functional testing using tempest-lib already
21:14:25 <mtreinish> tempest doesn't use the python-*clients
21:14:27 <stevebaker> mtreinish: do you see out-of-tree defcore tests being a thing?
21:14:53 <mtreinish> stevebaker: the vision I had was things that were in defcore would be in the tempest tree, and we'd adjust the scope to match as things were added
21:15:03 <stevebaker> ok
21:15:36 <mtreinish> but if we end up hitting the same scaling problems because defcore tries to tackle too many things (like we once did in tempest) then the plugin interface gives us a good crutch
21:16:49 <rockyg> thanks, mtreinish!  Can I invite you to give your vision to a defcore meeting?
21:17:16 <johnthetubaguy> OK, lets move on
21:17:17 <johnthetubaguy> #topic Base feature deprecation policy
21:17:20 <mtreinish> rockyg: sure you can invite me, but I'm not sure I'll be able to make it :)
21:17:25 <johnthetubaguy> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html
21:17:30 <ttx> I sent an email about our base feature deprecation policy last week
21:17:36 <ttx> link above
21:17:39 <ttx> The goal was to check if the proposed base policy was matching what was generally done in the field
21:17:46 <ttx> I had a few answers, but far from the whole spectrum
21:17:55 <ttx> The current proposal says: "a feature deprecated during the M development cycle should
21:17:55 <ttx> still appear in the M and N releases and cannot be removed before the beginning of the O development cycle."
21:18:03 <ttx> That is what we call "a minimum of n+2 deprecation"
21:18:10 <ttx> Some said we should do a minimum of n+1 instead.
21:18:17 <ttx> Some said features should be n+2, but config options should be n+1 (as long as they don't remove a feature)
21:18:25 <ttx> What would be acceptable ? What do you think you are currently enforcing in your projects, if anything ?
21:18:29 <bknudson> I could deprecate something today and remove it in a month.
21:18:42 <bknudson> if we went with n+1
21:19:04 <johnthetubaguy> I liked the points sdague was making on that thread
21:19:17 <jokke_> .
21:19:17 <jokke_> 03
21:19:17 <jokke_> .3
21:19:19 <jungleboyj> In Cinder we generally shoot for n+1.  Doesn't always happen though.  We do at least n+1
21:19:26 <jokke_> sorry
21:19:29 <johnthetubaguy> for continues deployers, you kinda want a minimum time frame to some extent
21:19:35 <ttx> bknudson: yeah, which is why the minimum propsoed would be n+2
21:20:09 <jokke_> how about stating it full cycle, more like a calendar year?
21:20:11 <bknudson> n+2 makes more sense. slow but steady wins the race.
21:20:16 <ttx> johnthetubaguy: so n+1 with a minimum of 3 months, or something
21:20:39 <johnthetubaguy> ttx: yes, although the simplicity of n+2 is quite nice, it feels a bit long as a baseline
21:21:01 <ttx> jokke_: so one aspect of it is that to know that a feature is deprecated you need to experience it through one "release"
21:21:08 <ttx> at least
21:21:22 <johnthetubaguy> certainly Nova is generally doing n+1 as a minimum, but when we are unsure/worried, we wait much longer, but thats not really a good policy statement
21:21:54 <ttx> we had unwritten common rules in the past, but they were so unwritten that everyone interpreted them differently :)
21:22:15 <ttx> the policy would be a minimum guarantee
21:22:29 <ttx> It's also fine is some projects are too young to follow it
21:22:35 <jungleboyj> johnthetubaguy: That sounds like our's.  :-)
21:22:37 <notmyname> swift's policy is "don't break clients and operators must be able to upgrade with no cluster downtime)"
21:23:14 <ttx> notmyname: but would you remove a feature or a config option without marking it deprecated for some time ?
21:23:15 <fungi> though also a good rule of thumb is that when projects are too young to follow normal deprecation, they should stick with 0.x.x version numbers
21:23:53 <fungi> (same as for inability to make guarantees on backward compatibility)
21:24:04 <ttx> fungi: we may be able to enforce that at some point (when all the >=1.0.0 projects happen to follow the minimum rule)
21:24:28 <fungi> yep, here's hoping the current crop of projects are already mature!
21:24:47 <johnthetubaguy> ttx: just for clarity, +1 your config statement, certainly Nova tried to ensure we don't force any config changes when doing an upgrade, assuming you dealt with all the deprecation messages in your logs from last time first, i.e. n+1 deprecation timeframe
21:24:47 <ttx> notmyname: "don't break clients" is a bit vague. Is removing a feature they depend on "breaking" them ?
21:25:21 <fungi> also, all clients? only clients you know exist? only clients developed in cooperation with the swift dev team?
21:25:28 <jokke_> I'd say at least with config options, you should be able to upgrade to next version without breaking anything ... what I mean is that if config option changes you should be able to upgrade your running code first and after that if you don't need roll back you can go and upgrage your configs
21:25:31 <notmyname> ttx: matters most with operators. removing features breaks clients unless you bump the API version. for ops, removing a feature (normally one that's controlled by a config var) means that the new code must accept the old config file and still work. and document it extensively in release notes
21:26:27 <notmyname> fungi: all clients. ie don't remove stuff from the api (or change existing functionality) without bumping the api version
21:26:42 <fungi> mad props for api versioning and stability
21:27:07 <jokke_> regarding that topic I'd like to hear wider opinion? How about defaults and how you deprecate them?
21:27:26 <ttx> notmyname: I guess the question becomes.. when you bump the API version, do you still support the previous API version ?
21:27:32 <notmyname> ttx: yes
21:27:39 <bknudson> how long would we need to continue to support keystoneclient 1.x if we released a 2.x?
21:27:41 <ttx> notmyname: and for how long ?
21:27:47 <clarkb> so in theory grenade enforces that N -> N+1 work without config or api changes as long as we have coverage for those things
21:27:48 <notmyname> ttx: but, it hasn't happened yet. ;-)
21:27:51 <bknudson> and what support would the library get?
21:27:55 <jokke_> This as example we moved to default images api v2 in glanceclient shell when we moved to 1.0.0
21:28:02 <notmyname> ttx: we're still "supporting" clients written six years ago on the same API
21:28:12 <clarkb> but it does not currently hve a way to enforce that in N -> N+2
21:28:27 <clarkb> maybe we can start with what grenade makes easy and work from there as its implementable?
21:28:40 <ttx> notmyname: right, so this is about setting expectations. If you were to stop supporting them, would you be OK with a minimum of n+2 deprecation warning.
21:28:57 <ttx> I bet you would, in that hypothetical case
21:29:00 <fungi> in the spirit of "if it's not tested it's broken" don't claim we do things if we can't test that we really do them
21:29:43 <notmyname> ttx: that presupposes that we would stop supporting them. there's no intention of that today
21:29:44 <ttx> so you can assert that you would follow the minimum deprecation policy
21:29:57 <notmyname> ttx: sure. I guess
21:30:06 <notmyname> ttx: or "at least" ;-)
21:30:11 <ttx> notmyname: right. So the original version of this change had a "never-deprecate-anything" assertion
21:30:24 <fungi> ∞>=2
21:30:25 <ttx> that was mostly meant for swift
21:30:55 <ttx> but people told me that was a bit unrealistic and that we should only do a minimum assertion (but projects can obviously promise to do much better)
21:31:53 <ttx> i.e. the tag says "you can expect that if this project ever deprecates something, you would have some advance notice through a deprecation warning for n cycles"
21:31:55 <notmyname> jokke_: to your point about config values, we've changed defaults before. always respect explicit values, and defaults should always work.
21:32:06 <ttx> (at the very least)
21:32:11 <notmyname> jokke_: and be explicit in docs + release notes about what they are
21:32:29 <johnthetubaguy> notmyname: same experience in Nova
21:32:32 <jokke_> notmyname: yes ... that far I do fully agree
21:32:51 <notmyname> ttx: yup. that seems reasonable.
21:33:04 <ttx> ok, anyway, no point in discussing that here, please answer to the thread and describe what you think you can assert you would at least follow
21:33:13 <fungi> though worth admitting that there are always going to be implicit defaults you don't realize exist until you find you want to change some behavior and add a configuration knob, so having some warning period before tweaking that is always helpful
21:33:33 <ttx> I'll take the whole feedback and cook up something we can communicate to our users
21:33:38 <notmyname> ttx: seems that it's more important that there *is* a deprecation policy. not as much what the N is. ie as a deployer know that config keys are good for a while. whatever the policy states
21:33:51 <ttx> notmyname: agreed
21:33:58 <johnthetubaguy> fungi: we did that for our periodic tasks, they were mixed up with 0 or -1 turning things off or using the default period, we gave that a cycle of warnings
21:34:03 <jokke_> notmyname: we bumped major version to try to make clear that this happened and documented it. The big cry that was raised was that someone who doesn't bother to read release notes might break their shellscripts if upgrading
21:34:53 <ttx> they need to know project X is past the crazy initial period wheer you can break users and deployers every other day. That's all this tag is meant to communicate
21:35:04 <ttx> which is why we want most mature projects to be able to assert it
21:35:05 <notmyname> jokke_: yeah. that's tough. IMO that comes down to the client side again, not the ops side
21:35:08 <johnthetubaguy> ttx: +1 thats very very valuable
21:35:27 <fungi> people who don't read might break things. this too is a universal constant
21:35:29 <jokke_> well this happened with tripleO gate where the new version was just pulled in and surprise v1 and v2 apis are not the same, but the big outcry did not come from there
21:35:39 <jungleboyj> fungi: ++
21:35:43 <ttx> we don't have incubation or experimental m�arks anymore, this is a way to comunicate the same type of information
21:35:58 <notmyname> fungi: and through no fault of their own, especially when considering transitive dependencies
21:36:00 <ttx> anywa, thanks for listening, and please contribute to that thread with your project data
21:36:02 <notmyname> fungi: (sometimes)
21:36:28 <johnthetubaguy> cool, good topic
21:36:34 <johnthetubaguy> #topic Open Discussion
21:36:35 <notmyname> ttx: this seems to be a great fit with the new release tags. (semver)
21:36:37 <lifeless> hi
21:36:46 <lifeless> I want to pimp two things
21:36:47 * fungi is unsure whether mùarks is a typo or new vocabulary to be assimilated
21:36:48 <lifeless> https://review.openstack.org/#/c/218070/
21:36:49 <lifeless> and
21:36:49 <jokke_> thanks for bringing that up ttx I think it's ever more important topic now with big tent and lots of variety
21:36:57 <lifeless> https://review.openstack.org/#/c/204073/
21:37:11 <lifeless> the first is moving testr to be run in a separate environment to the code-under-test
21:37:23 * ttx stops correcting typos after a given time of the day
21:37:51 <lifeless> It should be straight forward; I think I've spoken to enough folk about it - plus the big thread - but please do comment
21:38:10 <lifeless> the second is gus' privsep blueprint, strictly speaking its an oslo blueprint, but it will affect everyone as they adopt it
21:38:20 <lifeless> its in very-very-very fine tuning mode now IMO
21:38:39 <lifeless> I'd like to be able to get both approved before the summit, so that we don't need summit time on them
21:39:03 <fungi> or so that we can use summit time to get a headstart putting them into place
21:39:18 <ttx> lifeless: thx for pointing that one out, I definitely need to read that one (the rootwrap replacement)
21:39:20 <lifeless> fungi: for folk that get time to do stuff at summit, sure :)
21:39:23 <fungi> rather than arguing over the color
21:39:47 <johnthetubaguy> or colour
21:39:52 * johnthetubaguy hides
21:39:52 <timrc> zaro, I've been thinking some about your last comment to https://review.openstack.org/#/c/205097/ -- I'm not sure we should do any special handling / inference based on the API documentation this is expected behavior... http://javadoc.jenkins-ci.org/hudson/model/Node.html
21:40:30 <timrc> zaro, So I think the client should interpret a "" node_name as being "master" but that should not be the responsibility of the gearman-worker plugin.
21:40:40 <fungi> timrc: cross-project or wrong channel?
21:40:44 <timrc> doh
21:40:48 <timrc> Sorry lol
21:41:16 <johnthetubaguy> so I have been pondering Nova's current application of String Freeze
21:41:28 <johnthetubaguy> to cut a long story short, I think we were being a bit too strict
21:41:41 <johnthetubaguy> forcing bug fixes to remove log messages, as not to violate freeze
21:42:01 <johnthetubaguy> where really users would probably prefer an untranslated log instead of a hidden error
21:42:10 <mordred> johnthetubaguy: ++
21:42:16 <mordred> as a user, I would prefer that
21:42:16 <johnthetubaguy> at least, thats what I have been wondering
21:42:22 <johnthetubaguy> anyways, I attempted to write that up here:
21:42:23 <johnthetubaguy> https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#String_Freeze
21:42:42 <mordred> to be fair - I am an english speaking user, so my feelings on untranslated strings are likely not to be trusted
21:42:49 <lifeless> translated ops logs have never made sense to me
21:42:49 <johnthetubaguy> Been talking to the folks over on #openstack-l18n and they seem quite receptive to the idea
21:42:55 <lifeless> client logs, different thing
21:43:03 <johnthetubaguy> mordred: I went through exactly the same thought process
21:43:07 <fungi> i would have interpreted the spirit of the freeze as "don't invalidate the work already completed by translators if you can help it" but adding to the pile seems fine
21:43:30 <johnthetubaguy> fungi: yeah, thats basically what I put in that wiki page
21:43:43 <ttx> johnthetubaguy: adding strings is much less evil to translators to modifying one.
21:43:50 <ttx> than*
21:43:58 <rockyg> Better a foreign symbol error/warning than silent fail.  ++ johnthetubaguy
21:44:04 <clarkb> but if you do modify them do not change the interpolation stuff
21:44:14 <ttx> modifying an existing one they may have already translated is evil because it throws away translation work
21:44:21 <fungi> yeah, they're unlikely to hit 100.00000% translated so a few added strings during the freeze ought not be harmful
21:44:24 <johnthetubaguy> ttx: yes, I hadn't made the connection before talking with them today, for some reason, but I totally get that now
21:44:25 <ttx> adding one is just adding another line to their work pile
21:44:33 <johnthetubaguy> fungi: +1
21:44:37 <ttx> it's not evil unless you are one week before release
21:44:53 <johnthetubaguy> ttx: yeah, totally get that *now* I sat down and thought about it
21:45:39 <johnthetubaguy> so we have been interpreting things a bit too literally, just wanted to share that incase others were doing something similar
21:45:59 <bknudson> the guidelines https://wiki.openstack.org/wiki/StringFreeze aren't correct?
21:46:18 <bknudson> "String freeze means that we cannot add new strings"
21:46:40 <bknudson> the wiki seems to be the opposite of what we discussed here.
21:46:56 <fungi> yeah, i concur
21:47:12 <johnthetubaguy> bknudson: yeah, thats the old rules we were applying, and I noticed they seemed a bit crazy
21:47:41 <johnthetubaguy> so should I update https://wiki.openstack.org/wiki/StringFreeze to reflect what we said above
21:47:43 * ttx checks wiki
21:48:01 <fungi> an earlier version of that wiki said "proposed changes containing modifications in user-facing strings"
21:48:10 <fungi> bisecting now to see when/why that changed
21:48:16 <johnthetubaguy> would that update look a bit like this (ideally with many less words): https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#String_Freeze
21:48:17 <ttx> oh, that was "improved" a lot since I last touched it
21:48:49 <johnthetubaguy> fungi: I guess we called logs user facing at some point
21:49:06 <ttx> johnthetubaguy: feel free to come to something more sensible with the I18n/Docs teams. All this is to facilitate their work, so they decide what matters to them and what doesn't
21:49:06 <johnthetubaguy> which was a bit silly
21:49:29 * mordred once again points out that "user" is a TERRIBLE word in our world
21:49:33 <johnthetubaguy> ttx: yeah, I have an action to send them the above wiki, didn't get to that
21:49:34 <fungi> https://wiki.openstack.org/w/index.php?title=StringFreeze&diff=47151&oldid=46049
21:49:37 <ttx> like clarkb said, maybe modifying strings ar ok as long
21:49:45 <fungi> did not include any explanation of why that was changed, unfortunately
21:49:54 <ttx> ...are ok as long as you keep the interpolation up
21:50:00 <johnthetubaguy> mordred: +1 needs diss-abiguation, and I need a dictionary
21:50:05 <bknudson> put that file in git/gerrit!
21:50:16 <mordred> johnthetubaguy: yah. and a thesaurus
21:50:23 <johnthetubaguy> mordred: yup
21:50:27 * rockyg overloads another friendly word so it becomes meaningless in OpenStack....hah, take that!
21:50:42 <ttx> johnthetubaguy: if you manage to come up with something better that is OK with them, feel free to update the wiki page
21:50:56 <fungi> bknudson: yeah, lack of code review is the primary reason we've been moving so much from the wiki to git in the past year
21:51:24 * jokke_ takes user as ops running their cloud and end-user as that poor fella clicking horizon
21:51:31 <ttx> this could be described in the project team guide somewhere
21:51:35 <johnthetubaguy> where do we want this to go, if I put it in gerrit?
21:51:45 <johnthetubaguy> ah, project team guide would work
21:52:15 <fungi> when you have a project team guide hammer, problems like this certainly look like nails
21:52:16 <johnthetubaguy> OK, is anyone jumping up and down to do that, or should I take that action?
21:52:18 <ttx> johnthetubaguy: yeah, even if some projects wouldn't follow those, describing that common community practice there sounds like the right place
21:52:37 <fungi> johnthetubaguy: seems as good a home as any
21:52:42 <johnthetubaguy> cool
21:53:08 <johnthetubaguy> #action johnthetubaguy to add string freeze description into project team guide
21:53:28 <johnthetubaguy> that version fungi found from dolph seems quite good, back in 2014
21:53:39 <johnthetubaguy> cool, thats all for me
21:53:46 <johnthetubaguy> any more?
21:54:15 <rockyg> can you remove the text from the wiki and put a pointer to the project guide when you're done?
21:54:40 <johnthetubaguy> rockyg: totally will do, will update the wiki first
21:54:59 <rockyg> thanks!
21:55:21 <johnthetubaguy> cool, thank you all
21:55:28 <jokke_> big hand to ttx and dhellmann for herding us towards one more release and ttx being all around the place for one summit as well :)
21:55:40 <elmiko> hear hear
21:55:45 <ttx> thx!
21:55:45 <johnthetubaguy> enjoy your morning/afternoon/lunch/sleep all!
21:55:48 <jokke_> thnx all
21:55:50 <johnthetubaguy> jokke_ +1
21:55:50 <ttx> sleep!
21:55:51 <rockyg> huzzah!
21:55:54 <jroll> jokke_++
21:55:56 <johnthetubaguy> #endmeeting