I have personally taken the policy that GMT and UTC are invalid timezones for meetings

no meeting I schedule will ever use them

I'll start it, gimme a sec

gotta pull up the thingy

Meeting started at 2026-03-11 15:14:19 UTC

once the meeting is close to 50% non-NorAm people, personally I also think EST is the worst choice. because DST really should die and the US-based DST is the worst (overly long)

The Meeting name is 'CentOS Hyperscale SIG'

!hi

Michel Lind (salimma) - he / him / his

!hi

Neal Gompa (ngompa) - he / him / his

!hi

!hi

Sorry, `!startmeeting` must be called by itself

bots are not botting today

!hi

Raymond Colebaugh (rcolebaugh) - he / him / his

Pawel Zmarzly (pawo2500) - he / him / his

Davide Cavalca (dcavalca) - he / him / his

!hi

Gabriele Mambrini (gmambro) - he / him / his

*cough* US centrism

lol no

I'm fine with any timezone that real people live in :)

I wouldn't care this much if it weren't for most of the world with DST with _differing_ DST policies

lol no, I don't care that much which one as long as it's one people live in... and really it's only because most of the world has some variation of DST, and the DST policies are all different

I use US/Eastern because it's where _I_ live, and if I'm the organizer, reason stands I need to be there 😅

yeah, but if you schedule a meeting and 80% of the people are not in NorAm you probably should not use EST

anyway...

we used Europe/London for FESCo so 🤷‍♂️

I'm flexible, just don't make me get up at 7am for a meeting

btw can we start with a quick topic? removal of inactive members

I went through four years of that and it sucked

I think we should start, anyway, we're almost halfway through the hour

oof right

oh yes my attendance in Fedora meetings is very low when I was on the us west coast

it's almost impossible to square having west coast and central europe people in the same meeting

let's discuss membership cleanup?

pzmarzly

any US timezone and Australia is equally ahrd

any US timezone and Australia is equally hard

sure

jinx. matrix must be laggy

that was what made the openSUSE Board meetings suck for me

so, i contacted all people in red over a week ago

some people replied saying they actually want to be removed since they are doing something else now

most people didn't even reply

i made a list in https://gitlab.com/CentOS/Hyperscale/tracker/-/work_items/151#note_3150534391

@conan_kudo:matrix.org @davide:cavalca.name do either of you want to go update FAS and docs?

I think no reply should result in removal, it's been long enough )

but based on this we should write down the policy for next time

we should list people removed in the docs somewhere

yeah so about that, i wanted to document the process in the docs

probably as former members in the membership page or something like that

except we never thought what the process should be

emeritus of something

- At least 1 Hyperscale build on CBS in the last year, OR

We kindly ask that members meet at least one of the following criteria:

# Activity requirements

so i propose something like this:

We use [an automation](https://gitlab.com/CentOS/Hyperscale/misc/inactivity-monitoring) to identify members who may not have had a chance to meet these criteria recently. If flagged, members will be reached out to, and if we don't hear back within a week, we'll remove them from the active roster — but they are always welcome to rejoin at any time. See [this GitLab tracking issue](https://gitlab.com/CentOS/Hyperscale/tracker/-/work_items/151) for an example of how this process works.

- Expressing interest in staying active in the SIG and being reachable via email and Matrix.

- At least 1 GitHub contribution to Hyperscale repos in the last year, OR

we discussed the emeritus thing

we probably want to do it for *some* people but not all?

s/GitHub/GitLab/

for most of the rest 'former members' are ok, but I'm totally happy listing people like Justin as emeritus

yes

(months ago in a previous meeting, I mean)

the founding members are special enough IMO

pfff muscle memory

or former board sponsor like Thomas

oh lovely a bunch of us have a hard stop for our next meeting in half an hour

so since we start late let's not dilly dally

yeah I think this is good enough

we can iterate on it from there

anyone opposed?

salimma has already given cookies to pawo2500 during the F43 timeframe

thanks Pawel for taking point on this

This sounds reasonable to me

Davide Cavalca: are you able to execute on this with pzmarzly?

yep we'll take care of it

anything else on this?

I have another followup and one announcement

do we want to do it regularly?

ok

go for it

yearly probably

cleanup should be every 6 months or 1 year yeah

we're lazy so let's do one year?

but if it's one year we have to decide when to do it - 'spring cleaning' or 'fall cleaning'

spring cleaning is more "idiomatic" ;)

lets continue spring

so yeah we can say let's do it after the next time the spring EL release is out

so next April/May ish

makes sense for me

ok, for my follow up

we used to have automation to file bugs saying "hey package foo is outdated" - but a) it ran on openshift and broke and b) nobody knows how it works, since the Intel folks iirc left, and c) we moved from Pagure

and we never figured out how to be able to track different upstreams flexibly (some package, we package the latest, some we track Fedora, some we track centos)

so this tool aims to do all that. I haven't plugged in the ability to track a specific upstream (either directly via something like the Debian watch file, or piggybacking the fedora release-monitoring.org site - which is not very reliable so maybe not a good idea anyway)

but it works, you can specify an inventory to track, it can file and update bugs, and let you search for update requests that are not grabbed by anyone yet

I need to hook it up to gitlab next, so if anyone knows how to set up a periodic job on gitlab, please ping me after this :)

my favorite feature is 'show me open update requests and add the ones I'm not tracking yet to an inventory file'

question/comment/suggestions?

you want to look at this doc: https://docs.gitlab.com/ci/pipelines/schedules/

thanks

scheduled pipelines are not my favorite feature because it turns into a nightmare for auditing due to tons of logged jobs and there's no fulltext search

but it's there at least

can't be worse than our deprecated internal cron :)

if scheduled pipelines are not good enough, i can set up some VPS for that, since I have related plans. i'll follow up with you @salimma:fedora.im

it's mostly a pain if there's a mix of pipelines ind ifferent projects

it's mostly a pain if there's a mix of pipelines in projects

since you can't filter them

VPS seems overkill, we can also have a todo item to run the tool every meeting or something :)

but something like AWS lambda would work

one follow up: i'm not sure what is the benefit of task management features in the CLI? the consolidated view on https://gitlab.com/groups/CentOS/Hyperscale/-/work_items is pretty good and IMO we should look at it directly more often

fair question, yeah now that we're on gitlab it's less necessary. I think I only added it because we need it to update the inventory anyway, but I don't plan on adding too many features to it

second follow up: once we have issues created, i think it would be cool to have automated MR creation for every issue. wdyt?

yes, we discussed this in passing recently

we should follow up with the packit folks

ah, right

since they have the ability to trigger packit runs from bugzilla, and we want to be able to trigger it from issues with the right tag

be careful as there are different strategies depending on the package source

I intentionally made the issue subject identical to make their job easier :)

yeah, I wonder if we can customize packit enough for this

probably need to discuss with packit about it

anyway, for another time :)

you have another item to bring up?

easiest will be the ones where we track upstream directly, and the one where we take the fedora package as is without touching the spec

next one is announcement, so I'll let others do follow ups if there's any

i'm good

easiest-easiest will be the one where we take c10 rpm and rebuild as c9 :D

now that the conference stuff is over, I can finally get back to hyperscale kernel rebase

woohoo

hopefully libbpf now being in hyperscale helps a bit with that

I know it seems like I'm dragging my feet, but there's been a lot going on

happens to all of us

crossing fingers it'll just be slow and not painful

fwiw this conferene season is super useful for that as Peter Georg's talk about building kernels was really useful

yup

fwiw this conference season is super useful for that as Peter Georg's talk about building kernels was really useful

alright, I think that's it, so let's move onto...

ok, I lie, I have two

our kernel folks need this to run bpf self tests, as 1.5.0 in centos 9 is too old

amusingly, CentOS 10 has libbpf 1.7.0 which ... does not actually exist. it's built as part of the CentOS kernel which lies about being 6.12 :) -- so turns out the lie goes both up and down

so I have not built libbpf for hs.el10, I just hope the stock one is actually good enough

I see what you mean about c9s-hs kernel builds

yeah, this was one of the things that broke the kernel compile iirc

yup

it finally hit our internal kernel devs too

hah

so my stuff _is_ occasionally useful to you guys :P

so this one is just taken from f44. rawhide has an extra patch to build kernel 7, but it comes with a warning that it breaks building older kernels so... I did not take it

weirdly the commit is by Debian Luca

yeah that's probably smart

(the one in systemd)

oh, bluca

I try to avoid Rawhide anyway if fedora stable/branched is new enough

ok, ... 10 mins left. one more thing

so relmon is for keeping hs packages up to date. this one is more for... doing due diligence before bringing something into hyperscale, or before rebasing

that's handy

it does impact check and flag what dependents of the package you're replacing (if it exists) will be affected

one follow up I have is fedrq does not understand Hyperscale so we can't do impact check on other HS packages yet

neat

but it take repo definitions externally, so next step we can keep those out of tree, and then try upstreaming them

can you ship a layered package for hyperscale configs, similar to what we do for mock?

yes, we definitely can

that's probably better then

I think it does the right thing - it can look in multiple directories (usr/share, etc, homedir)

yeah idk if hs is important enough to be included in the core anyway. but we can flag this to gotmax once we have it written

that's it from me

quick thing - someone wants to review https://gitlab.com/CentOS/Hyperscale/docs/-/merge_requests/1?

we can look after the meeting

we have a few minutes left

after the *next* meeting :P

JefPL is presenting his sandbox thing

I guess this is where we should look now?

yeah I guess

nothing new, and the newest item was already covered

so let's go on to...

yeah, and maybe https://gitlab.com/groups/CentOS/Hyperscale/-/merge_requests to see if any work is stuck

I updated the inactive pruning to be in progress with assignees

is there a Kanban view of the work items? that's the one feature I like from Pagure

yes

issue boards is the kanban

https://gitlab.com/groups/CentOS/Hyperscale/-/boards

it's not great, but it's there

https://gitlab.com/groups/CentOS/Hyperscale/-/boards

aha. well this is probably easier for doing reviews during the meeting than the work item list

I'll play with it so we can see it by status since open/close is ... not that useful

ok, no membership thingies, so moving on to...

pzmarzlysince you're the de facto issue editor, Neal kept wanting to rename this to "Open Floor" :)

I hate typing this :P

and oof we should wrap this up in the next couple of mins, while the next meeting is still in the intro phase

yeah, times up

thanks everyone

self-destruct time!