16:00:08 <gmann> #startmeeting tc
16:00:08 <opendevmeet> Meeting started Wed Feb 15 16:00:08 2023 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:08 <opendevmeet> The meeting name has been set to 'tc'
16:00:11 <gmann> #topic Roll call
16:00:12 <dansmith> o/
16:00:13 <noonedeadpunk> o/
16:00:14 <gmann> o/
16:00:22 <rosmaita> o/
16:00:39 <arne_wiebalck> o/
16:00:44 <gmann> today Absence:
16:00:52 <gmann> knikolla[m] have conflict with another meeting
16:00:54 <gmann> JayF out 2/15 (covid)
16:01:15 <slaweq> o/
16:01:17 <gmann> JayF: sad to hear that, please take rest and get well soon
16:01:38 <rosmaita> ++ for JayF, -- for covid
16:01:50 <gmann> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
16:01:53 <gmann> today agenda ^^
16:01:53 * bauzas sits in the back
16:02:41 * gmann bauzas you are very welcome to come front :)
16:02:50 <gmann> let's start
16:02:53 <gmann> #topic Follow up on past action items
16:03:07 <gmann> noonedeadpunk to add PyPi access policy in governance documentation
16:03:44 <noonedeadpunk> yeah, I didn't have progress on that :(
16:03:50 <gmann> noonedeadpunk: any update on this? or you want to discuss it in the next topic
16:03:58 <gmann> k, let's continue this
16:04:03 <noonedeadpunk> I do have it in my backlog though
16:04:09 <gmann> #action noonedeadpunk to add PyPi access policy in governance documentation
16:04:14 <gmann> noonedeadpunk: thanks
16:04:18 <noonedeadpunk> so let's leave it for the next week
16:04:36 <gmann> sure
16:04:41 <gmann> gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job
16:05:05 <gmann> ah, I missed it. no progress on this. will continue this item
16:05:11 <gmann> #action gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job
16:05:35 <gmann> #topic Gate health check
16:05:48 <gmann> and this is reason I am stuck on my many other tasks :)
16:06:06 <dansmith> yeah, so,
16:06:07 <gmann> dansmith: please go ahead to summarize the gate sitatuion now
16:06:10 <spotz> o/
16:06:23 <dansmith> things are slightly better now that we merged a couple of things, but it's still pretty rough IMHO
16:06:29 <dansmith> gmann: did the timeout thing merge?
16:06:54 <bauzas> definitely rough IMHO
16:06:54 <dansmith> I've got a patch up that as of this morning looks like it may be dropping mysql memory usage by a considerable amount, but I need to check the impact on performance to see if it's worth it
16:07:04 <dansmith> but that may be an option to help with the OOMs
16:07:10 <dansmith> but there are still a lot of other failures
16:07:18 <dansmith> tons of volume-related failures specifically,
16:07:30 <dansmith> and then lots of other small cuts which together make the situation pretty bad
16:07:54 <dansmith> I fixed the glance locations occasional-failure, and then fixed that fix
16:08:03 <gmann> ok
16:08:09 <bauzas> we also had some problems with dhcp clients
16:08:12 <dansmith> gmann has a patch up to increase the timeout, which we were going to do temporarily, but ...
16:08:16 <bauzas> (at least in the nova CI)
16:08:27 <dansmith> bauzas: yep, plenty of unable to ssh to test instances for sure
16:08:30 <gmann> timeout series is merged and I abandon the temporary increasing the timeout https://review.opendev.org/q/topic:bug%252F2004780
16:08:56 <dansmith> oh, so no timeout increase because of the test splitting you mean?
16:09:12 <gmann> dansmith: let's observe the timeout failure now and if we still get then I will retsore that https://review.opendev.org/c/openstack/tempest/+/873472
16:09:16 <gmann> yeah
16:09:17 <dansmith> ack
16:09:34 <dansmith> I didn't see any timeouts this morning in the few patches I looked at, so perhaps that helped
16:09:57 <gmann> k, let's continue monitor those
16:10:04 <dansmith> yeah
16:10:14 <dansmith> but we really need more help working on these things I think
16:10:21 <dansmith> especially the volume ones
16:10:28 <dansmith> maybe after FF people will be able to jump on them more
16:10:37 <gmann> yeah
16:10:48 <noonedeadpunk> Well, I'm not sure if it's timeout that helped or load reduced on providers, as we instead of timeouts now get some jobs just 5mins before timeout
16:11:10 <noonedeadpunk> And waaaay less timeouts for the past week overall
16:11:25 <gmann> ack
16:12:00 <gmann> gate is very unstable overall during this release especially in last month
16:12:07 <gmann> or since tox4 time
16:12:08 <bauzas> indeed
16:12:19 <dansmith> pretty much all year so far I think
16:12:26 <gmann> yeah
16:12:26 <bauzas> first time I'm creating an etherpad to track the most CI failures
16:12:39 <gmann> humm. but +1 on tracking those
16:12:49 <gmann> anything else on gate things?
16:13:22 <gmann> #topic TC 2023.1 tracker status checks
16:13:26 <gmann> #link https://etherpad.opendev.org/p/tc-2023.1-tracker
16:13:45 <gmann> please go ahead if anyone has any updates on the items assigned the to them
16:14:29 <gmann> one is from slaweq on guidelines of using release version/project version in doc/releasenotes
16:14:38 <gmann> and patch is up for review #linkhttps://review.opendev.org/c/openstack/governance/+/872769
16:14:49 <gmann> please check and vote/feedback accordingly
16:15:50 <gmann> rosmaita: anything you would like to update on i18? I think you had meeting? sorry i missed that
16:15:56 <gmann> was it yesterday or today?
16:16:00 <rosmaita> yesterday
16:16:03 <gmann> k
16:16:36 <rosmaita> quick update ... we figured out some basic stuff that weblate needs to set up the server
16:16:55 <slaweq> thx for all reviews in advance :)
16:16:57 <rosmaita> i have a meeting with weblate tomorrow to convey that so they can start setting up the host
16:17:23 <gmann> ++
16:17:49 <rosmaita> after its setup and openid for openinfra is working, we will move all discussion to the openstack-discuss list
16:18:14 <gmann> perfect
16:18:17 <rosmaita> and start working on recruiting an engineer to handle the weblate-to-gerrit plumbing
16:18:38 <gmann> hope we get volunteer
16:19:20 <rosmaita> yeah, the idea is to simultaneously look for a volunteer while refining the job description
16:19:36 <gmann> ack
16:19:44 <rosmaita> in case we need to ask the foundation for short term contractor support
16:19:53 <rosmaita> that's all
16:19:53 <gmann> rosmaita: feel free to propose it as upstream opportunity also if that can help
16:20:08 <rosmaita> ok, that is a good idea
16:20:27 <gmann> that will help to showcase the volunteer asking in that place too
16:20:38 <gmann> or even for long term also
16:20:52 <rosmaita> yeah, and i just remembered, i am supposed to revise the proposed survey of operators
16:21:10 <rosmaita> to get some data but also see if they are interested in sponsoring an engineeer
16:21:20 <gmann> TC survey questions or i18 SIG specific ?
16:21:57 <rosmaita> i18n specific
16:22:00 <gmann> k
16:22:18 <gmann> thanks rosmaita for all your hard work on this
16:22:23 <rosmaita> we have some on the current user survey, this was going to use a web survey to get more immediate data
16:22:35 <gmann> ok
16:22:47 <gmann> that is good idea
16:23:15 <rosmaita> this is the survey (not revised yet): https://forms.zohopublic.com/rosmaitafossdev/form/OpenStacktranslationsusageandcontributionsurvey/formperma/9W0PYjoo61tAShU9B1GQj3m52K43uty-KtXDhIlOUe4
16:23:21 <rosmaita> (nice url!)
16:23:32 <gmann> :)
16:23:49 <gmann> #link https://forms.zohopublic.com/rosmaitafossdev/form/OpenStacktranslationsusageandcontributionsurvey/formperma/9W0PYjoo61tAShU9B1GQj3m52K43uty-KtXDhIlOUe4
16:24:03 <rosmaita> i'll get that updated in the next day or so
16:24:13 <gmann> thanks for the link. anything else rosmaita on this?
16:24:15 <gmann> cool
16:24:48 <rosmaita> main difference is that we know for sure now about the hosted weblate, so focus will be on usage and will you contribute to the engineering "plumbing" work
16:25:13 <rosmaita> that's all
16:25:23 <gmann> sure, getting usage data is always helpful
16:25:32 <gmann> k. let's move to next topic
16:25:34 <gmann> #topic Deprecation process for TripleO
16:25:40 <gmann> #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032083.html
16:26:04 <gmann> you might have seen the email discussion about TripleO shutting down the maintenance
16:26:18 <gmann> and we discussed it in this week or last week may be
16:26:44 <gmann> but with more TC members here, let's conclude the way and get agreement and then to communicate the same to TripleO team
16:27:17 <gmann> should I give some background on what is the situation or everyone knows/remember?
16:27:39 <noonedeadpunk> I think we should do business as usual and just follow deprecation path
16:28:14 <gmann> TripleO has stable/wallaby and then stable/zed. no stable/xena, stable/yoga. and team want to maintain until stable/wallby
16:28:31 <slaweq> I agree with noonedeadpunk - this isn't really different than deprecation of e.g. networking-midonet which we did some time ago
16:28:35 <noonedeadpunk> with adding some note to the readme file of stable/zed that it needs some maintenance and it's not realted in any way to coordinated release or smth
16:28:56 <noonedeadpunk> not sure about ^ even
16:28:59 <gmann> difference is stable/zed exist and team does not want to maintain it as last supported stable branch
16:29:19 <dansmith> slaweq: it's different in that a later release will be deprecated before an earlier one right?
16:29:40 <gmann> so marking deprecated until stable/wallaby which means it will be supported as last maintain branch but keep stable/zed also open
16:29:47 <noonedeadpunk> yeah, so maybe we just don't deprecate later release?
16:29:49 <gmann> and master README.rst explain it
16:30:15 <dansmith> noonedeadpunk: yeah, so not deprecating zed and just putting a comment in the readme that it's not maintained?
16:30:23 <slaweq> yeah, why not deprecate master only and keep stable releases as they are now
16:30:25 <gmann> it will be deprecated but without support just for anyone want to maintain it from there
16:30:28 <noonedeadpunk> gmann: I think master README will say that project is deprecated?
16:30:29 <dansmith> it's weird because if we have a CVE or something, putting that into wallaby will create a regression in zed
16:30:36 <gmann> noonedeadpunk: yes
16:30:37 <noonedeadpunk> dansmith: yup
16:30:45 <bauzas> Wallaby is EM, so whatever support they will provide, it's still EM
16:31:20 <noonedeadpunk> I wonder how they're going to do that as some projects already EOLed W
16:31:24 <noonedeadpunk> anyway
16:31:45 <gmann> yeah, that is ok as they need to do retirement that time anyways
16:31:49 <gmann> in normal situation also
16:33:06 <gmann> I think we are ok with this- Deprecate until stable/zed, maintained until stable/wallaby, and mark the project as deprecated on master.
16:33:12 <noonedeadpunk> dansmith: I think the main risk in case of CVE if somebody will even backport to Z, they may jsut refuse to merge
16:33:19 <bauzas> is TripleO following the stable policies ? I guess no by what I can read
16:33:19 <dansmith> gmann: I'm confused by your use of "until"
16:33:31 <noonedeadpunk> +1
16:33:58 <noonedeadpunk> bauzas: nope, they're independant. So stable/zed is basically not coordinated stable/zed I assume...
16:34:13 <dansmith> yeah, it's really confusing
16:34:15 <gmann> dansmith: I do not think they follow stable policy, at least not in this list #link https://docs.openstack.org/project-team-guide/stable-branches.html#project-teams-which-asserted-they-follow-the-stable-branch-policy
16:34:23 <gmann> bauzas: ^^
16:34:32 <gmann> yeah
16:34:32 <bauzas> eek
16:34:59 <dansmith> I'm not sure what the stable thing really has to do with it
16:35:27 <gmann> so  Project is deprecated, the last stable branch maintained is stable/wallaby, but keep stable/zed content but deprecated
16:35:31 <dansmith> they have a stable/zed branch that looks to match the coordinated release and be stable with everything else, but since they don't claim to support stable officially, they're not on the hook for any of it?
16:36:11 <dansmith> s/it/those procedures/ ?
16:36:27 <gmann> yeah, we just need to give more clarity on its last supported branch and if where to start if anyone else want to take maintenance
16:37:00 <dansmith> the optics of this for the wider community are just really unfortunate, but okay
16:37:02 <gmann> as situation is already not good we cannot improve that at this stage
16:37:08 <gmann> yeah
16:37:34 <gmann> and something we as TC should work to avoid this situation in future for any project
16:38:50 <gmann> let's do the voting on the agreement for best possible way forward
16:38:55 <gmann> is this ok "The project can be deprecated, the last stable branch maintained is stable/wallaby, but keeps stable/zed content and deprecated"
16:39:00 <slaweq> the most obvious thing to avoid such thing is to have more diversity in projects :)
16:39:14 <noonedeadpunk> what does mean ` keeps stable/zed content and deprecated` in fact?
16:39:15 <dansmith> slaweq: ++ :)
16:39:16 <gmann> slaweq: yeah
16:39:27 <dansmith> noonedeadpunk: not delete the branch
16:39:47 <gmann> yeah and not supported/maintained also
16:39:56 <slaweq> we can write many rules in our docs but if project is maintained by single company and this company changes its goals, docs won't help
16:39:57 <noonedeadpunk> yeah, but what `deprecated` basically means in this case
16:40:07 <gmann> which will be clarified in master README.rst
16:40:24 <gmann> noonedeadpunk: it reflect that any further work on stable/zed is stopped
16:40:31 <noonedeadpunk> as deprecation of master means that all content and CI jobs should be removed
16:40:48 <gmann> on master  only and content removal also
16:41:13 <spotz[m]> Has anyone from another company stepped up to take over?
16:41:17 <rosmaita> i think we need to write this out on an etherpad or something, a one line sentence is not sufficient to describe what we are going to vote on
16:41:21 <gmann> but here we want to keep stable/zed content in case anyone want to proceed further
16:41:32 <gmann> spotz[m]: no afaik
16:41:39 <dansmith> gmann: no content removal at all, but you mean delete the master branch I assume?
16:41:59 <gmann> dansmith: yes, on delete the master means content removal on master
16:42:09 <noonedeadpunk> but not branch itself
16:42:20 <gmann> that is what deprecation step is. 'delete the master content but keep on stable'
16:42:28 <dansmith> gmann: right, what I mean is they claimed they were going to "empty commit" the branch.. you mean just delete the master branch but not do the empty commit anywhere right?
16:42:34 <gmann> ah yes, not the branch it will have README.rst
16:42:39 <arne_wiebalck> will the existence of stable/zed not confuse people? (not sure this is feasible/sensible, but renaming the zed branch may be better)
16:42:39 <noonedeadpunk> so basically following regular deprecation process, and adjust readme to reflect support status of stable/zed
16:42:46 <gmann> dansmith: yes.
16:43:05 <gmann> arne_wiebalck: it is confusing but renaming it can create more confusion
16:43:07 <dansmith> arne_wiebalck: rename to what?
16:43:24 <arne_wiebalck> dansmith: to anything but stable/zed
16:43:27 <dansmith> arne_wiebalck: its already confusing that they're dropping support for newer stuff and only supporting the old stuff, so I think confusion is guaranteed
16:43:35 <arne_wiebalck> dansmith: heh
16:43:43 <dansmith> arne_wiebalck: the-artist-formerly-known-as-stable/zed ?
16:43:45 <gmann> noonedeadpunk: basically yes. the exception is to keep stable/zed content but not maintained
16:43:49 <arne_wiebalck> dansmith: perfect
16:44:16 <arne_wiebalck> dansmith: I bet there will be people seeing this branch as the latest with content, use it, and read the README much later
16:44:17 <noonedeadpunk> not maintained until someone step in :p
16:44:19 <noonedeadpunk> but yeah
16:44:33 <gmann> yes
16:44:37 <dansmith> arne_wiebalck: for sure, which is why it's very strange to be doing this at all
16:44:47 <arne_wiebalck> dansmith: yes
16:44:51 <dansmith> but renaming it to something else doesn't make it less confusing, just ... different confusing
16:44:53 <noonedeadpunk> I was just confused with haping `deprecated` and `keeping content` as these 2 are contraversary
16:45:05 <noonedeadpunk> *having
16:45:10 <dansmith> noonedeadpunk: why?
16:45:15 <arne_wiebalck> see, we have confused noonedeadpunk already :-D
16:45:33 <gmann> that is what we can explain it in README.rst on stable/zed also
16:45:34 <spotz[m]> Hehe
16:45:41 <rosmaita> not just noonedeadpunk, i am completely confused
16:46:02 <gmann> dansmith: basically if content is there we should support otherwise it is retirement means remove content
16:46:17 <opendevreview> Vishal Manchanda proposed openstack/governance master: Step 3: Retire repo from the Governance repo - Retire xstatic-font-awesome  https://review.opendev.org/c/openstack/governance/+/872837
16:46:27 <dansmith> I'm just never in favor of *deleting* content that already exists.
16:46:27 <noonedeadpunk> dansmith: well, it's part of our "deprecation" definition kind of https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-repository
16:46:33 <bauzas> honestly, I'm quite disappointed by the idea of empty committing stable/zed
16:46:38 <bauzas> or EOLing
16:46:39 <gmann> here we are saying stable/zed is deprecated so content is there but it is not maintained as deprecated things are maintained until they are removed
16:46:41 <bauzas> just to be clear
16:46:58 <bauzas> as some people may take bits of TripleO without fully subscribing to their delivery model
16:47:02 <gmann> that is why we want to keep stable/zed content
16:47:33 <bauzas> and we can imagine people contributing to the puppet modules on stable/zed without really contributing to the core of tripleo
16:47:38 <gmann> other option is just delete the stable/zed and anyone want to maintain it further can take master ^HEAD ?
16:47:50 <dansmith> noonedeadpunk: ack, for full project deletion I see (not sure I really like that either) but that clearly doesn't apply here directly
16:47:51 <noonedeadpunk> let's please avoid saying that zed is deprecated then ?
16:47:55 <rosmaita> so, why don't we just -em all existing branches of triple-o, and then it's up to the community to decide what branch they want to maintain?
16:48:07 <dansmith> rosmaita: even wallaby?
16:48:17 <rosmaita> well, wallaby is em already, right?
16:48:21 <dansmith> in tripleo?
16:48:32 <noonedeadpunk> let's say it's unmaintained, unsupported or whatever, but not retired or deprecated :)
16:48:44 <gmann> marking stable/zed as -em also good option and do not mark it deprecdated or so
16:48:52 <dansmith> it
16:49:09 <rosmaita> is train -em in triple-o?
16:49:15 <fungi> point to keep in mind, "tripleo" consists of lots of git repositories, some of which don't have stable branches, so whatever plan you arrive at needs to take that into account as well
16:49:15 <dansmith> no
16:49:19 <noonedeadpunk> but -em is a tag - not a branch
16:49:24 <dansmith> noonedeadpunk: right
16:49:28 <noonedeadpunk> in regular release process
16:49:34 <gmann> yes
16:49:43 <dansmith> rosmaita: train, wallaby, zed are all top-level non-em branches in THT for example
16:50:02 <dansmith> https://github.com/openstack/tripleo-heat-templates/branches
16:50:02 <rosmaita> yes, but once it's tagged -em, the Extended Maintenance rules apply
16:50:12 <opendevreview> Vishal Manchanda proposed openstack/governance master: Add xstatic-angular-fileupload as Horizon team deliverables  https://review.opendev.org/c/openstack/governance/+/873845
16:50:38 <gmann> but marking zed as -em ahead will serve the purpose right? it is there bt not maintained by core team so anyone else want they can take it up
16:50:49 <fungi> remember that you can't un-tag, so once em always em even if some new team offers to pick up maintenance of those newer branches
16:50:55 <dansmith> okay I thought -em was after the tag has *replaced* the branch
16:51:09 <dansmith> I see they have a wallaby-em tag as well as a stable/wallaby branch
16:51:11 <fungi> -eol tags replace deleted branches
16:51:14 <noonedeadpunk> Well, the only way we can do branch renaming - is saying that it should not have been created as stable/zed at the first place as project has independant release cadence
16:51:24 <gmann> -em will use the last rleased tag/hash
16:51:53 <noonedeadpunk> But then we're inventoing smth new and it will be waaaay harder to communicate
16:52:01 <gmann> so how about this - "Following regular deprecation process, and mark stable/zed as EM" ?
16:52:17 <noonedeadpunk> How marking it as EM will help us?
16:52:36 <dansmith> yeah, I'm confused on that
16:52:39 <rosmaita> no more releases, only best effort CI, community maintenance
16:52:47 <gmann> it will say core team does not maintain it so it is like unmaintained until anyone else come and maintain it
16:53:00 <gmann> so new maintainer can fix things there
16:53:17 <gmann> rosmaita:  no 'community maintenance' also
16:53:35 <gmann> as tripleo team will not maintain it
16:54:09 <dansmith> so wallaby is em in their tree and has no notice in the readme, so users just have to know that it also has the tag so it must be EM?
16:54:13 <bauzas> if you really want to be pragmatic, just mention that stable/zed becomes untested
16:54:26 <gmann> either we can reflecty the statement of 'not maintained ' in stable/zed README or mark it as -em
16:54:32 <dansmith> point being, I normally look at the release cycles stuff to determine what is supported and not, and don't look at the fact that there's this em tag
16:54:51 <gmann> k
16:54:53 <noonedeadpunk> imo if we want to make an exception in our policies now - then we can go straight to EOLing Zed
16:54:56 <dansmith> so I think just tagging zed as em is something we'll tell ourselves matters, but I don't think it will actually communicate much to the average person
16:55:13 <noonedeadpunk> =1 ^
16:55:18 <noonedeadpunk> *+1
16:55:21 <rosmaita> https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
16:55:46 <slaweq> +1
16:55:50 <gmann> EOLing zed means branch will be deleted so anyone using it form there cannot fix bug
16:56:09 <gmann> which is not ok but we do not have better option I think
16:56:40 <bauzas> why can't we just mention that the zuul coverage will be minimal ?
16:56:46 <dansmith> could we ask the tripleo team if they would consider just supporting the zed branch like normal?
16:56:52 <bauzas> that ^
16:56:59 <dansmith> I suspect there may be not much work to be done there
16:57:08 <gmann> but they said no in email right. they want to support only stable/wallby
16:57:09 <slaweq> ++
16:57:10 <dansmith> so maybe they can just agree to that as a compromise
16:57:18 <dansmith> gmann: I know what they said
16:57:33 <bauzas> they also said they gonna reduce the number of jobs they run
16:57:39 <bauzas> (iirc)
16:57:58 <slaweq> IMHO we should at least try to ask them - maybe they will agree and it will be much easier :)
16:58:03 <dansmith> slaweq: ++
16:58:06 <clarkb> even if they don't you could stick a note in the readme and add big warnings to documentation that the branch lives to enable others to help but the original team isn't around anymore. Then send it through the nromal eol process when zed reaches that point
16:58:11 <gmann> sure, we can ask.
16:58:29 <noonedeadpunk> +1 for clarkb's proposal
16:58:29 <dansmith> clarkb: agree, that'd be my preferred backup plan
16:58:32 <gmann> not sure we have them here but let me ask on email thread
16:58:45 <gmann> and we will continue the discussion in next meeting to conclude
16:58:45 <fungi> given they indicated an interest in only maintaining one (old, already em) branch, it would make more sense to just officially retire the project and let them maintain the old version downstream
16:58:49 <dansmith> basically not break our process, but if we don't have anyone to support it, just be upfront about it and let it age out naturally
16:59:18 <gmann> yeah if they can support that will be best way
16:59:20 <noonedeadpunk> fungi: oh, radical approach, I like that :)
16:59:22 <gmann> we are out of time, let's move to next topic
16:59:47 <rosmaita> fungi: ++
16:59:53 <gmann> we might need to extend the meeting if everyone is ok for that ?
17:00:13 <slaweq> I will need to drop (wife's waiting for me) - sorry
17:00:57 <gmann> k, let me go to one last topic then and others we can discuss in next meeting
17:01:04 <gmann> #topic Select time to discuss the 'Less Diversity' discussion with foundation staff (Jimmy)
17:01:35 <gmann> as we discussed in board sync up call, as next step we can have discussion with Jimmy (foundation staff) on diversity things
17:01:48 <gmann> when we want to schedule it? in PTG or before PTG ?
17:01:51 <rosmaita> maybe we should call this "Need More Diversity" so people don't get the wrong idea
17:02:07 <slaweq> :)
17:02:11 <gmann> sure
17:02:30 <gmann> if on PTG then we can schdule that time otherwise I will put the poll to select the time
17:02:31 <spotz[m]> I need to run but yeah don’t confuse folks;)
17:02:54 <dansmith> gmann: ptg sounds good to me
17:03:14 <slaweq> for me too
17:03:29 <arne_wiebalck> +1
17:03:38 <rosmaita> ptg sounds good
17:03:57 <gmann> cool, I will put this in PTG etherpad "Need More Diversity"
17:04:13 <gmann> ok. thanks all for joining
17:04:22 <gmann> #endmeeting