| *** dasm is now known as dasm|off | 01:49 | |
| opendevreview | Merged openstack/election master: Add Slawek Kaplonski for TC in Bobcat https://review.opendev.org/c/openstack/election/+/873756 | 02:26 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/election master: Adding Takashi Kajinami candidacy for Storlets PTL https://review.opendev.org/c/openstack/election/+/873838 | 02:31 |
| gmann | tkajinam thanks for taking care of many project leadership. I think its 3rd nomination from you. | 02:34 |
| tkajinam | gmann, o/ yeah heat, puppet and storlets. storlets is mostly my personal project nowadays, though. | 02:38 |
| gmann | +1 | 02:38 |
| opendevreview | Dale Smith proposed openstack/election master: Adding Dale candidacy for Adjutant https://review.opendev.org/c/openstack/election/+/873839 | 02:40 |
| opendevreview | Shuai Qian proposed openstack/election master: Add qian.shuai candidacy for Magnum PTL https://review.opendev.org/c/openstack/election/+/873851 | 03:45 |
| opendevreview | Shuai Qian proposed openstack/election master: Add qian.shuai candidacy for Magnum PTL https://review.opendev.org/c/openstack/election/+/873851 | 05:38 |
| *** blarnath is now known as d34dh0r53 | 06:47 | |
| opendevreview | Vishal Manchanda proposed openstack/governance master: Add xstatic-angular-fileupload as Horizon team deliverables https://review.opendev.org/c/openstack/governance/+/873845 | 07:11 |
| opendevreview | James Page proposed openstack/election master: Add jamespage TC candidacy https://review.opendev.org/c/openstack/election/+/873884 | 08:57 |
| opendevreview | James Page proposed openstack/election master: Add jamespage TC candidacy https://review.opendev.org/c/openstack/election/+/873884 | 09:12 |
| opendevreview | James Page proposed openstack/election master: Add jamespage TC candidacy https://review.opendev.org/c/openstack/election/+/873884 | 09:13 |
| opendevreview | Grzegorz Grasza proposed openstack/election master: Adding Grzegorz Grasza candidacy for Barbican PTL https://review.opendev.org/c/openstack/election/+/873885 | 09:16 |
| opendevreview | James Page proposed openstack/election master: Add jamespage TC candidacy https://review.opendev.org/c/openstack/election/+/873884 | 10:23 |
| bauzas | man, stopping at 6pmUTC leads you missing some nice conversations about diversity | 10:42 |
| bauzas | and I have some stories to tell here | 10:42 |
| bauzas | but meh | 10:42 |
| bauzas | too late | 10:42 |
| opendevreview | Artem Goncharov proposed openstack/election master: Add Artem Goncharov PTL candidacy for SDK/CLI https://review.opendev.org/c/openstack/election/+/873898 | 11:22 |
| opendevreview | Rafael Weingartner proposed openstack/election master: Adding Rafael Weingärtner candidacy for Cloudkitty https://review.opendev.org/c/openstack/election/+/873902 | 11:44 |
| opendevreview | Rafael Weingartner proposed openstack/election master: Adding Rafael Weingärtner candidacy for Cloudkitty https://review.opendev.org/c/openstack/election/+/873902 | 12:11 |
| *** dasm|off is now known as dasm | 14:01 | |
| dtantsur | hey, this is probably the wrong channel to ask, but I have no idea where to go. Is https://wiki.openstack.org/wiki/Internship_ideas kept up-to-date? | 14:04 |
| rosmaita | dtantsur: probably not | 14:20 |
| bauzas | https://wiki.openstack.org/w/index.php?title=Internship_ideas&action=info says the last update is 4 years old (wow, time flies) | 14:21 |
| bauzas | but fwiw, I'd be more than happy to find ways to attract new contributors to the nova project and mentor interns | 14:21 |
| bauzas | (that relates to the diversity discussion that happened yesterday) | 14:22 |
| rosmaita | heh, i made the last change | 14:29 |
| bauzas | while Nova is on a better shape in terms of contributions from on-off people, I think I'd appreciate if somehow we could encourage those on-off contributors to engage more with the project as we're struggling to attract new maintainers | 14:44 |
| dtantsur | rosmaita, bauzas, wdyt about deleting this page? I'm afraid it may be misleading. People keep finding it somehow. | 14:56 |
| bauzas | dtantsur: I'd propose to leave a big fat introduction in the page saying this info *may* be stale but people are free to reach the stakeholders | 14:56 |
| rosmaita | dtantsur: maybe put a note there redirecting to the "help wanted" list? | 14:57 |
| rosmaita | bauzas: ++ | 14:57 |
| bauzas | that yeah | 14:57 |
| dtantsur | yeah, anything that will prevent confused people coming to Outreachy coordinators with it :) | 14:57 |
| bauzas | any URL or pointer directing to onboarding seems a good enough fit to be kept :D | 14:58 |
| rosmaita | dtantsur: are you the outreachy coordinator for openstack? | 14:58 |
| dtantsur | rosmaita: I am indeed (together with another person) | 14:59 |
| rosmaita | thanks for doing that | 14:59 |
| dtantsur | sure thing :) | 14:59 |
| rosmaita | do you have a page somewhere? we could mention that at the top of the wiki page you found | 14:59 |
| dtantsur | rosmaita: https://www.outreachy.org/apply/project-selection/#openstack for interns, https://www.outreachy.org/communities/cfp/openstack/ for mentors | 15:00 |
| rosmaita | ok, cool ... i will put a big yellow block at the top of the page saying what bauzas suggested and also suggesting looking into outreachy and the help wanted list | 15:01 |
| bauzas | dtantsur: I don't have a list of topics in my head but if you have anyone fancy wanting to work on some nova bits, feel free to reach to me | 15:03 |
| *** Guest3941 is now known as diablo_rojo | 15:03 | |
| bauzas | dtantsur: we also tried to identify a few features that are low hanging fruits, worth a look for someone to start | 15:03 |
| *** d34dh0r53 is now known as d34dh0r5- | 15:24 | |
| *** d34dh0r5- is now known as d34dh0r53 | 15:27 | |
| *** d34dh0r53 is now known as blarnath | 15:28 | |
| *** blarnath is now known as d34dh0r53 | 15:28 | |
| knikolla[m] | I won't be able to attend the TC meeting today. Have a scheduling conflict I can't get out of. | 15:32 |
| gmann | ack | 15:33 |
| *** pojadhav- is now known as pojadhav | 15:36 | |
| gmann | tc-members: meeting time | 16:00 |
| gmann | #startmeeting tc | 16:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'tc' | 16:00 |
| gmann | #topic Roll call | 16:00 |
| dansmith | o/ | 16:00 |
| noonedeadpunk | o/ | 16:00 |
| gmann | o/ | 16:00 |
| rosmaita | o/ | 16:00 |
| arne_wiebalck | o/ | 16:00 |
| gmann | today Absence: | 16:00 |
| gmann | knikolla[m] have conflict with another meeting | 16:00 |
| gmann | JayF out 2/15 (covid) | 16:00 |
| slaweq | o/ | 16:01 |
| gmann | JayF: sad to hear that, please take rest and get well soon | 16:01 |
| rosmaita | ++ for JayF, -- for covid | 16:01 |
| gmann | #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting | 16:01 |
| gmann | today agenda ^^ | 16:01 |
| * bauzas sits in the back | 16:01 | |
| * gmann bauzas you are very welcome to come front :) | 16:02 | |
| gmann | let's start | 16:02 |
| gmann | #topic Follow up on past action items | 16:02 |
| gmann | noonedeadpunk to add PyPi access policy in governance documentation | 16:03 |
| noonedeadpunk | yeah, I didn't have progress on that :( | 16:03 |
| gmann | noonedeadpunk: any update on this? or you want to discuss it in the next topic | 16:03 |
| gmann | k, let's continue this | 16:03 |
| noonedeadpunk | I do have it in my backlog though | 16:04 |
| gmann | #action noonedeadpunk to add PyPi access policy in governance documentation | 16:04 |
| gmann | noonedeadpunk: thanks | 16:04 |
| noonedeadpunk | so let's leave it for the next week | 16:04 |
| gmann | sure | 16:04 |
| gmann | gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job | 16:04 |
| gmann | ah, I missed it. no progress on this. will continue this item | 16:05 |
| gmann | #action gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job | 16:05 |
| gmann | #topic Gate health check | 16:05 |
| gmann | and this is reason I am stuck on my many other tasks :) | 16:05 |
| dansmith | yeah, so, | 16:06 |
| gmann | dansmith: please go ahead to summarize the gate sitatuion now | 16:06 |
| spotz | o/ | 16:06 |
| dansmith | things are slightly better now that we merged a couple of things, but it's still pretty rough IMHO | 16:06 |
| dansmith | gmann: did the timeout thing merge? | 16:06 |
| bauzas | definitely rough IMHO | 16:06 |
| 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:06 |
| dansmith | but that may be an option to help with the OOMs | 16:07 |
| dansmith | but there are still a lot of other failures | 16:07 |
| dansmith | tons of volume-related failures specifically, | 16:07 |
| dansmith | and then lots of other small cuts which together make the situation pretty bad | 16:07 |
| dansmith | I fixed the glance locations occasional-failure, and then fixed that fix | 16:07 |
| gmann | ok | 16:08 |
| bauzas | we also had some problems with dhcp clients | 16:08 |
| dansmith | gmann has a patch up to increase the timeout, which we were going to do temporarily, but ... | 16:08 |
| bauzas | (at least in the nova CI) | 16:08 |
| dansmith | bauzas: yep, plenty of unable to ssh to test instances for sure | 16:08 |
| gmann | timeout series is merged and I abandon the temporary increasing the timeout https://review.opendev.org/q/topic:bug%252F2004780 | 16:08 |
| dansmith | oh, so no timeout increase because of the test splitting you mean? | 16:08 |
| 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 |
| gmann | yeah | 16:09 |
| dansmith | ack | 16:09 |
| dansmith | I didn't see any timeouts this morning in the few patches I looked at, so perhaps that helped | 16:09 |
| gmann | k, let's continue monitor those | 16:09 |
| dansmith | yeah | 16:10 |
| dansmith | but we really need more help working on these things I think | 16:10 |
| dansmith | especially the volume ones | 16:10 |
| dansmith | maybe after FF people will be able to jump on them more | 16:10 |
| gmann | yeah | 16:10 |
| 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:10 |
| noonedeadpunk | And waaaay less timeouts for the past week overall | 16:11 |
| gmann | ack | 16:11 |
| gmann | gate is very unstable overall during this release especially in last month | 16:12 |
| gmann | or since tox4 time | 16:12 |
| bauzas | indeed | 16:12 |
| dansmith | pretty much all year so far I think | 16:12 |
| gmann | yeah | 16:12 |
| bauzas | first time I'm creating an etherpad to track the most CI failures | 16:12 |
| gmann | humm. but +1 on tracking those | 16:12 |
| gmann | anything else on gate things? | 16:12 |
| gmann | #topic TC 2023.1 tracker status checks | 16:13 |
| gmann | #link https://etherpad.opendev.org/p/tc-2023.1-tracker | 16:13 |
| gmann | please go ahead if anyone has any updates on the items assigned the to them | 16:13 |
| gmann | one is from slaweq on guidelines of using release version/project version in doc/releasenotes | 16:14 |
| gmann | and patch is up for review #linkhttps://review.opendev.org/c/openstack/governance/+/872769 | 16:14 |
| gmann | please check and vote/feedback accordingly | 16:14 |
| gmann | rosmaita: anything you would like to update on i18? I think you had meeting? sorry i missed that | 16:15 |
| gmann | was it yesterday or today? | 16:15 |
| rosmaita | yesterday | 16:16 |
| gmann | k | 16:16 |
| rosmaita | quick update ... we figured out some basic stuff that weblate needs to set up the server | 16:16 |
| slaweq | thx for all reviews in advance :) | 16:16 |
| rosmaita | i have a meeting with weblate tomorrow to convey that so they can start setting up the host | 16:16 |
| gmann | ++ | 16:17 |
| rosmaita | after its setup and openid for openinfra is working, we will move all discussion to the openstack-discuss list | 16:17 |
| gmann | perfect | 16:18 |
| rosmaita | and start working on recruiting an engineer to handle the weblate-to-gerrit plumbing | 16:18 |
| gmann | hope we get volunteer | 16:18 |
| rosmaita | yeah, the idea is to simultaneously look for a volunteer while refining the job description | 16:19 |
| gmann | ack | 16:19 |
| rosmaita | in case we need to ask the foundation for short term contractor support | 16:19 |
| rosmaita | that's all | 16:19 |
| gmann | rosmaita: feel free to propose it as upstream opportunity also if that can help | 16:19 |
| rosmaita | ok, that is a good idea | 16:20 |
| gmann | that will help to showcase the volunteer asking in that place too | 16:20 |
| gmann | or even for long term also | 16:20 |
| rosmaita | yeah, and i just remembered, i am supposed to revise the proposed survey of operators | 16:20 |
| rosmaita | to get some data but also see if they are interested in sponsoring an engineeer | 16:21 |
| gmann | TC survey questions or i18 SIG specific ? | 16:21 |
| rosmaita | i18n specific | 16:21 |
| gmann | k | 16:22 |
| gmann | thanks rosmaita for all your hard work on this | 16:22 |
| rosmaita | we have some on the current user survey, this was going to use a web survey to get more immediate data | 16:22 |
| gmann | ok | 16:22 |
| gmann | that is good idea | 16:22 |
| rosmaita | this is the survey (not revised yet): https://forms.zohopublic.com/rosmaitafossdev/form/OpenStacktranslationsusageandcontributionsurvey/formperma/9W0PYjoo61tAShU9B1GQj3m52K43uty-KtXDhIlOUe4 | 16:23 |
| rosmaita | (nice url!) | 16:23 |
| gmann | :) | 16:23 |
| gmann | #link https://forms.zohopublic.com/rosmaitafossdev/form/OpenStacktranslationsusageandcontributionsurvey/formperma/9W0PYjoo61tAShU9B1GQj3m52K43uty-KtXDhIlOUe4 | 16:23 |
| rosmaita | i'll get that updated in the next day or so | 16:24 |
| gmann | thanks for the link. anything else rosmaita on this? | 16:24 |
| gmann | cool | 16:24 |
| 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:24 |
| rosmaita | that's all | 16:25 |
| gmann | sure, getting usage data is always helpful | 16:25 |
| gmann | k. let's move to next topic | 16:25 |
| gmann | #topic Deprecation process for TripleO | 16:25 |
| gmann | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032083.html | 16:25 |
| gmann | you might have seen the email discussion about TripleO shutting down the maintenance | 16:26 |
| gmann | and we discussed it in this week or last week may be | 16:26 |
| 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:26 |
| gmann | should I give some background on what is the situation or everyone knows/remember? | 16:27 |
| noonedeadpunk | I think we should do business as usual and just follow deprecation path | 16:27 |
| gmann | TripleO has stable/wallaby and then stable/zed. no stable/xena, stable/yoga. and team want to maintain until stable/wallby | 16:28 |
| 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 |
| 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 |
| noonedeadpunk | not sure about ^ even | 16:28 |
| gmann | difference is stable/zed exist and team does not want to maintain it as last supported stable branch | 16:28 |
| dansmith | slaweq: it's different in that a later release will be deprecated before an earlier one right? | 16:29 |
| 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 |
| noonedeadpunk | yeah, so maybe we just don't deprecate later release? | 16:29 |
| gmann | and master README.rst explain it | 16:29 |
| dansmith | noonedeadpunk: yeah, so not deprecating zed and just putting a comment in the readme that it's not maintained? | 16:30 |
| slaweq | yeah, why not deprecate master only and keep stable releases as they are now | 16:30 |
| gmann | it will be deprecated but without support just for anyone want to maintain it from there | 16:30 |
| noonedeadpunk | gmann: I think master README will say that project is deprecated? | 16:30 |
| dansmith | it's weird because if we have a CVE or something, putting that into wallaby will create a regression in zed | 16:30 |
| gmann | noonedeadpunk: yes | 16:30 |
| noonedeadpunk | dansmith: yup | 16:30 |
| bauzas | Wallaby is EM, so whatever support they will provide, it's still EM | 16:30 |
| noonedeadpunk | I wonder how they're going to do that as some projects already EOLed W | 16:31 |
| noonedeadpunk | anyway | 16:31 |
| gmann | yeah, that is ok as they need to do retirement that time anyways | 16:31 |
| gmann | in normal situation also | 16:31 |
| 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 |
| 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 |
| bauzas | is TripleO following the stable policies ? I guess no by what I can read | 16:33 |
| dansmith | gmann: I'm confused by your use of "until" | 16:33 |
| noonedeadpunk | +1 | 16:33 |
| noonedeadpunk | bauzas: nope, they're independant. So stable/zed is basically not coordinated stable/zed I assume... | 16:33 |
| dansmith | yeah, it's really confusing | 16:34 |
| 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 |
| gmann | bauzas: ^^ | 16:34 |
| gmann | yeah | 16:34 |
| bauzas | eek | 16:34 |
| dansmith | I'm not sure what the stable thing really has to do with it | 16:34 |
| gmann | so Project is deprecated, the last stable branch maintained is stable/wallaby, but keep stable/zed content but deprecated | 16:35 |
| 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:35 |
| dansmith | s/it/those procedures/ ? | 16:36 |
| 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:36 |
| dansmith | the optics of this for the wider community are just really unfortunate, but okay | 16:37 |
| gmann | as situation is already not good we cannot improve that at this stage | 16:37 |
| gmann | yeah | 16:37 |
| gmann | and something we as TC should work to avoid this situation in future for any project | 16:37 |
| gmann | let's do the voting on the agreement for best possible way forward | 16:38 |
| 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:38 |
| slaweq | the most obvious thing to avoid such thing is to have more diversity in projects :) | 16:39 |
| noonedeadpunk | what does mean ` keeps stable/zed content and deprecated` in fact? | 16:39 |
| dansmith | slaweq: ++ :) | 16:39 |
| gmann | slaweq: yeah | 16:39 |
| dansmith | noonedeadpunk: not delete the branch | 16:39 |
| gmann | yeah and not supported/maintained also | 16:39 |
| 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 |
| noonedeadpunk | yeah, but what `deprecated` basically means in this case | 16:39 |
| gmann | which will be clarified in master README.rst | 16:40 |
| gmann | noonedeadpunk: it reflect that any further work on stable/zed is stopped | 16:40 |
| noonedeadpunk | as deprecation of master means that all content and CI jobs should be removed | 16:40 |
| gmann | on master only and content removal also | 16:40 |
| spotz[m] | Has anyone from another company stepped up to take over? | 16:41 |
| 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 |
| gmann | but here we want to keep stable/zed content in case anyone want to proceed further | 16:41 |
| gmann | spotz[m]: no afaik | 16:41 |
| dansmith | gmann: no content removal at all, but you mean delete the master branch I assume? | 16:41 |
| gmann | dansmith: yes, on delete the master means content removal on master | 16:41 |
| noonedeadpunk | but not branch itself | 16:42 |
| gmann | that is what deprecation step is. 'delete the master content but keep on stable' | 16:42 |
| 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 |
| gmann | ah yes, not the branch it will have README.rst | 16:42 |
| 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 |
| noonedeadpunk | so basically following regular deprecation process, and adjust readme to reflect support status of stable/zed | 16:42 |
| gmann | dansmith: yes. | 16:42 |
| gmann | arne_wiebalck: it is confusing but renaming it can create more confusion | 16:43 |
| dansmith | arne_wiebalck: rename to what? | 16:43 |
| arne_wiebalck | dansmith: to anything but stable/zed | 16:43 |
| 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 |
| arne_wiebalck | dansmith: heh | 16:43 |
| dansmith | arne_wiebalck: the-artist-formerly-known-as-stable/zed ? | 16:43 |
| gmann | noonedeadpunk: basically yes. the exception is to keep stable/zed content but not maintained | 16:43 |
| arne_wiebalck | dansmith: perfect | 16:43 |
| 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 |
| noonedeadpunk | not maintained until someone step in :p | 16:44 |
| noonedeadpunk | but yeah | 16:44 |
| gmann | yes | 16:44 |
| dansmith | arne_wiebalck: for sure, which is why it's very strange to be doing this at all | 16:44 |
| arne_wiebalck | dansmith: yes | 16:44 |
| dansmith | but renaming it to something else doesn't make it less confusing, just ... different confusing | 16:44 |
| noonedeadpunk | I was just confused with haping `deprecated` and `keeping content` as these 2 are contraversary | 16:44 |
| noonedeadpunk | *having | 16:45 |
| dansmith | noonedeadpunk: why? | 16:45 |
| arne_wiebalck | see, we have confused noonedeadpunk already :-D | 16:45 |
| gmann | that is what we can explain it in README.rst on stable/zed also | 16:45 |
| spotz[m] | Hehe | 16:45 |
| rosmaita | not just noonedeadpunk, i am completely confused | 16:45 |
| gmann | dansmith: basically if content is there we should support otherwise it is retirement means remove content | 16:46 |
| 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 |
| dansmith | I'm just never in favor of *deleting* content that already exists. | 16:46 |
| 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 |
| bauzas | honestly, I'm quite disappointed by the idea of empty committing stable/zed | 16:46 |
| bauzas | or EOLing | 16:46 |
| 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 |
| bauzas | just to be clear | 16:46 |
| bauzas | as some people may take bits of TripleO without fully subscribing to their delivery model | 16:46 |
| gmann | that is why we want to keep stable/zed content | 16:47 |
| bauzas | and we can imagine people contributing to the puppet modules on stable/zed without really contributing to the core of tripleo | 16:47 |
| gmann | other option is just delete the stable/zed and anyone want to maintain it further can take master ^HEAD ? | 16:47 |
| 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 |
| noonedeadpunk | let's please avoid saying that zed is deprecated then ? | 16:47 |
| 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:47 |
| dansmith | rosmaita: even wallaby? | 16:48 |
| rosmaita | well, wallaby is em already, right? | 16:48 |
| dansmith | in tripleo? | 16:48 |
| noonedeadpunk | let's say it's unmaintained, unsupported or whatever, but not retired or deprecated :) | 16:48 |
| gmann | marking stable/zed as -em also good option and do not mark it deprecdated or so | 16:48 |
| dansmith | it | 16:48 |
| rosmaita | is train -em in triple-o? | 16:49 |
| 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 |
| dansmith | no | 16:49 |
| noonedeadpunk | but -em is a tag - not a branch | 16:49 |
| dansmith | noonedeadpunk: right | 16:49 |
| noonedeadpunk | in regular release process | 16:49 |
| gmann | yes | 16:49 |
| dansmith | rosmaita: train, wallaby, zed are all top-level non-em branches in THT for example | 16:49 |
| dansmith | https://github.com/openstack/tripleo-heat-templates/branches | 16:50 |
| rosmaita | yes, but once it's tagged -em, the Extended Maintenance rules apply | 16:50 |
| 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 |
| 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 |
| 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 |
| dansmith | okay I thought -em was after the tag has *replaced* the branch | 16:50 |
| dansmith | I see they have a wallaby-em tag as well as a stable/wallaby branch | 16:51 |
| fungi | -eol tags replace deleted branches | 16:51 |
| 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 |
| gmann | -em will use the last rleased tag/hash | 16:51 |
| noonedeadpunk | But then we're inventoing smth new and it will be waaaay harder to communicate | 16:51 |
| gmann | so how about this - "Following regular deprecation process, and mark stable/zed as EM" ? | 16:52 |
| noonedeadpunk | How marking it as EM will help us? | 16:52 |
| dansmith | yeah, I'm confused on that | 16:52 |
| rosmaita | no more releases, only best effort CI, community maintenance | 16:52 |
| gmann | it will say core team does not maintain it so it is like unmaintained until anyone else come and maintain it | 16:52 |
| gmann | so new maintainer can fix things there | 16:53 |
| gmann | rosmaita: no 'community maintenance' also | 16:53 |
| gmann | as tripleo team will not maintain it | 16:53 |
| 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 |
| bauzas | if you really want to be pragmatic, just mention that stable/zed becomes untested | 16:54 |
| gmann | either we can reflecty the statement of 'not maintained ' in stable/zed README or mark it as -em | 16:54 |
| 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 |
| gmann | k | 16:54 |
| noonedeadpunk | imo if we want to make an exception in our policies now - then we can go straight to EOLing Zed | 16:54 |
| 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:54 |
| noonedeadpunk | =1 ^ | 16:55 |
| noonedeadpunk | *+1 | 16:55 |
| rosmaita | https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance | 16:55 |
| slaweq | +1 | 16:55 |
| gmann | EOLing zed means branch will be deleted so anyone using it form there cannot fix bug | 16:55 |
| gmann | which is not ok but we do not have better option I think | 16:56 |
| bauzas | why can't we just mention that the zuul coverage will be minimal ? | 16:56 |
| dansmith | could we ask the tripleo team if they would consider just supporting the zed branch like normal? | 16:56 |
| bauzas | that ^ | 16:56 |
| dansmith | I suspect there may be not much work to be done there | 16:56 |
| gmann | but they said no in email right. they want to support only stable/wallby | 16:57 |
| slaweq | ++ | 16:57 |
| dansmith | so maybe they can just agree to that as a compromise | 16:57 |
| dansmith | gmann: I know what they said | 16:57 |
| bauzas | they also said they gonna reduce the number of jobs they run | 16:57 |
| bauzas | (iirc) | 16:57 |
| slaweq | IMHO we should at least try to ask them - maybe they will agree and it will be much easier :) | 16:57 |
| dansmith | slaweq: ++ | 16:58 |
| 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 |
| gmann | sure, we can ask. | 16:58 |
| noonedeadpunk | +1 for clarkb's proposal | 16:58 |
| dansmith | clarkb: agree, that'd be my preferred backup plan | 16:58 |
| gmann | not sure we have them here but let me ask on email thread | 16:58 |
| gmann | and we will continue the discussion in next meeting to conclude | 16:58 |
| 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 |
| 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:58 |
| gmann | yeah if they can support that will be best way | 16:59 |
| noonedeadpunk | fungi: oh, radical approach, I like that :) | 16:59 |
| gmann | we are out of time, let's move to next topic | 16:59 |
| rosmaita | fungi: ++ | 16:59 |
| gmann | we might need to extend the meeting if everyone is ok for that ? | 16:59 |
| slaweq | I will need to drop (wife's waiting for me) - sorry | 17:00 |
| gmann | k, let me go to one last topic then and others we can discuss in next meeting | 17:00 |
| gmann | #topic Select time to discuss the 'Less Diversity' discussion with foundation staff (Jimmy) | 17:01 |
| 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 |
| gmann | when we want to schedule it? in PTG or before PTG ? | 17:01 |
| rosmaita | maybe we should call this "Need More Diversity" so people don't get the wrong idea | 17:01 |
| slaweq | :) | 17:02 |
| gmann | sure | 17:02 |
| gmann | if on PTG then we can schdule that time otherwise I will put the poll to select the time | 17:02 |
| spotz[m] | I need to run but yeah don’t confuse folks;) | 17:02 |
| dansmith | gmann: ptg sounds good to me | 17:02 |
| slaweq | for me too | 17:03 |
| arne_wiebalck | +1 | 17:03 |
| rosmaita | ptg sounds good | 17:03 |
| gmann | cool, I will put this in PTG etherpad "Need More Diversity" | 17:03 |
| gmann | ok. thanks all for joining | 17:04 |
| gmann | #endmeeting | 17:04 |
| opendevmeet | Meeting ended Wed Feb 15 17:04:22 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-15-16.00.html | 17:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-15-16.00.txt | 17:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-15-16.00.log.html | 17:04 |
| arne_wiebalck | thanks gmann and everyone! | 17:04 |
| slaweq | o/ | 17:04 |
| gmann | FYI, election updates: we have 4 TC nominations + 1 yet to merge and 9 projects without nomination + 6 yet to merge | 17:06 |
| gmann | deadline for nomination is ~6.5 hrs from now | 17:06 |
| gmann | tc-members: need more review on these https://review.opendev.org/c/openstack/governance/+/873749 https://review.opendev.org/c/openstack/governance/+/872233 https://review.opendev.org/c/openstack/governance/+/872769 | 17:49 |
| gmann | could not cover these in meeting | 17:49 |
| opendevreview | Merged openstack/election master: Adding Takashi Kajinami candidacy for Storlets PTL https://review.opendev.org/c/openstack/election/+/873838 | 18:35 |
| opendevreview | Merged openstack/election master: Adding Grzegorz Grasza candidacy for Barbican PTL https://review.opendev.org/c/openstack/election/+/873885 | 18:35 |
| opendevreview | Merged openstack/election master: Add jamespage TC candidacy https://review.opendev.org/c/openstack/election/+/873884 | 18:35 |
| opendevreview | Merged openstack/election master: Adding Dale candidacy for Adjutant https://review.opendev.org/c/openstack/election/+/873839 | 18:35 |
| opendevreview | Merged openstack/election master: Add Artem Goncharov PTL candidacy for SDK/CLI https://review.opendev.org/c/openstack/election/+/873898 | 18:35 |
| opendevreview | Merged openstack/election master: Adding Rafael Weingärtner candidacy for Cloudkitty https://review.opendev.org/c/openstack/election/+/873902 | 18:35 |
| opendevreview | Merged openstack/governance master: Correct 'date' field https://review.opendev.org/c/openstack/governance/+/873749 | 20:17 |
| opendevreview | David Wilde proposed openstack/election master: Adding Dave Wilde candidacy for the Keystone project https://review.opendev.org/c/openstack/election/+/874029 | 20:49 |
| *** dasm is now known as dasm|off | 21:56 | |
| opendevreview | Merged openstack/election master: Adding Dave Wilde candidacy for the Keystone project https://review.opendev.org/c/openstack/election/+/874029 | 22:10 |
| tonyb | gmann: It's know moot but can you tag the repo at some stage in the next hour? | 23:09 |
| fungi | i thought we did it through release requests in openstack/releases over the past few years | 23:29 |
| fungi | tonyb: like https://review.opendev.org/856287 | 23:31 |
| tonyb | fungi: Ahh okay. I'll submit that and update the election docs | 23:32 |
| tonyb | fungi: they saye have the TC chair tag the repo, but an election offical can submit the chnage and ait for the chair to +1 it | 23:33 |
| fungi | precisely. the docs can be improved there | 23:34 |
| fungi | more likely you can get the tc chair to +1 something in gerrit quickly than wait for them to push a change | 23:34 |
| fungi | at least that's the approach i took when i was still officialing | 23:36 |
| fungi | for example, i pushed https://review.opendev.org/755636 as an election official a couple of years ago and just asked the tc chair to ack it | 23:38 |
| tonyb | gmann: https://review.opendev.org/c/openstack/releases/+/874039 based on discussions | 23:39 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!