Meeting started at 2026-04-28 17:00:34 UTC

The Meeting name is 'FESCo (2026-04-28)'

The Meeting Name is now fesco

!group members fesco

Members of fesco: Dave Cantrell, Fabio Valentini, Máirín Duffy, Jef Spaleta, Kevin Fenzi, ngompa (@conan_kudo:matrix.org, @ngompa:fedora.im, @pharaoh_atem:opensuse.org, @ngompa:kde.org, @ngompa:almalinux.im), salimma (@michel-slm:matrix.org, @salimma:fedora.im), Stephen Gallagher, Timothée Ravier, Zbigniew Jędrzejewski-Szmek

!hi

morning

zbyszek: Zbigniew Jędrzejewski-Szmek (zbyszek)

!hi

dcantrell: Dave Cantrell (dcantrell) - he / him / his

!hi

!hi

Fabio Valentini: Fabio Valentini (decathorpe) - he / him / his

zodbot sleepy today?

!hi

(was with the wrong matrix account

)

Timothée Ravier: Timothée Ravier (siosm) - he / him / his

ah, better 😆

aren't we all? :)

ok, we're only 5 yet, I'll give the others another minute

that was three minutes, let's start

!fesco 3597

**fesco #3597** (https://pagure.io/fesco/issue/3597):**[FastTrack] Change release EOL to _not_ move when the release slips**

● **Last Updated:** 19 hours ago

● **Assignee:** Not Assigned

● **Opened:** 6 days ago by zbyszek

This is a six-day-old fast-track ticket, so something clearly went wrong here. Let's discuss! Or vote in meeting.

whats the current tally at? I know I was +1 in ticket....

I count +4, with zbyszek implicitly +1 to his own proposal that would be +5.

just added a +1 for myself in the ticket

that's +6. still not enough for fast-track approval.

Yeah, I'm +1 to the proposal of course.

We can vote here.

It was only FastTrack because the bugzilla was on the F44 blocker list.

Proposal:

see https://pagure.io/fesco/issue/3597#comment-1012673

> "The N release EOL date is initially set as the Early Target Date + 5 weeks of the N+2 release. If the N+2 release slips past the Final Target date #1, the N release EOL date is shifted in the same way."

+1

+1

+1

+1

+1

!hi

Stephen Gallagher: Stephen Gallagher (sgallagh) - he / him / his

Sorry I'm late.

ohai

So, just to be clear, this is clarifying the policy to match what I (as maintainer of fedora-release) have been assuming was the policy?

Which is that the EOL is only modified for N-2 if N slips.

Mostly, yes, plus "no need to adapt if we hit the "early" target date."

And not under any other circumstances.

Right, that's how I read the proposal. +1

great, thanks

(I just wanted to make sure I had that right, so I don't flub it when I implement :) )

do we know where this is currently documented?

then with Michel's +1 in the ticket, we are at (+7, 0, -0) if I'm counting correctly

https://docs.fedoraproject.org/en-US/releases/lifecycle/#_maintenance_schedule

I'll tag it with "needs-documenting" after approval and keep the ticket open so we don't forget

I'm 99% sure that this was the intent of the policy we drafted several years ago, but we probably didn't document it correctly.

The phrasing in the schedule is "This is a changeable date and currently based off the Early Target Date".

Unfortunately that is ambiguous, because it doesn't clearly say *which * ETD.

Somehow, the established practice because to mean ETD of N, not N+2.

There may well be some releng and pgm docs that need updating too.

"Established practice" in the sense of the changes that were made in the schedule repo. The N-EOL was modified whenever N-Final slipped.

the schedule repo is kind of a problem right now

almost no one can edit apart from someone with access to special internal tool

We should probably add "update fedora-release of N-2` to the SOP at release.

Anyway, I think we should approve this and adjust the docs whenever we find something in disagreement.

I don't even know where this tool is

We should probably add "update fedora-release of N-2\` to the SOP when declared GO for GA.

IIUC it's a special calendaring tool that spits out gigabytes worth of XML :D

https://docs.fedoraproject.org/en-US/infra/release_guide/sop_final_release/#_bodhi_changes

IIRC it's called smartsheet(s?)

yes, this needs to be fixed and I think everyone wants to, just hasn't happened yet.

anyway we can hash that out in the PRs for updating the docs, don't think we need to discuss more during the meeting?

mooooving on.

!fesco 3568

● **Assignee:** Not Assigned

**fesco #3568** (https://pagure.io/fesco/issue/3568):**Fedora GNOME bugzilla auto-response and bug monitoring expectations**

● **Opened:** 2 months ago by carlwgeorge

● **Last Updated:** a week ago

so I am not sure what action(s) are proposed here?

> Can FESCo provide guidance on how this should be addressed?

Which is sufficiently broad or vague for anything to happen here :)

The action item from this ticket is:

i don't know what the right answer is, i just know the status quo is not ok

I think this is one of those packages where the upstream is also doing the packaging in Fedora and Fedora is the first target for new releases, etc

so having a Fedora bug tracker and an upstream bug tracker is kind of annoying

we should have a way in Fedora to allow a package to redirect bugs to a specific tracker

If `@gnome-sig` were a single person member of the `packager` group, would this still be acceptable behaviour?

I've been thinking about this for a bit, and to me this boils down to two questions, let me start with the first:

some packages are preferring to handle Fedora bugs directly upstream

It may be that this could be more revisited as part of bugzilla replacement...

My tl;dr version: GNOME has never maintained their Fedora packages' Bugzilla tickets to the level required by our packaging policies and has always insisted that bugs be filed upstream. Their recent change makes this very clear, but arguably hostile.

IMO how Bugzilla is handled is only one symptom of a larger problem here.

but the upstream gnome tracker is not exclusive for fedora. what happens in that scenario when a fedora user files a bug upstream, and an upstream dev closes and says it's fedora-specific?

Fabio Valentini: what is the 'behavior' ? auto posting to bugs that they are ignored?

well, yes, that and more ... but I don't want to digress

yeah, I get that. I'm not suggesting the right thing would happen, I'm just saying that _some_ packages out there want to converge their upstream and Fedora-specific bug trackers

well, I mean, can we force anyone to read / action something? Is saying "we don't monitor this, file upsteam" worse than silence?

don't know. I don't know who is maintaining gnome packages in fedora

The auto-responder has:

> This issue should only be kept open if it:

>

> 1. Relates to Fedora packaging or integration with other Fedora components

> 2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions

The problem I see with this is that bugs are ignored, *period*

i think there could be a solution here that just involves adjusting the bugzilla auto-response text

to me this is mostly about setting expectations, not forcing people to do anything

yeah...

true, but I would also like to hear from gnome or at least this package maintainer as to where they want Fedora bugs filed

Can we add a Bugzilla template for bugs filed against Gnome component that encourages filing non-packaging/non-Fedora-specific bugs upstream

some text that suggests upstream bugs are _prioritized_ would be much more acceptable than saying that downstream bugs are _ignored_

This message that shows _after_ a user has a already filed a bug is hostile

we can, but a problem with that is that many users if they are not packagers do not know the difference between a Fedora specific packaging bug and an upstream bug

Would it be possible to change the bug wizard / template for packages in this group?

Yeah, that's what I suggested

I am not sure it is possible.

exactly, it makes them feel like they wasted their time, and it's already a struggle to get users to file bugs

would need investigation.

I thought there was already a special one for kernel?

Why couldn't we do something similar for a set list of Gnome packages?

Well, if the user isn't sure, they should file it on Bugzilla it should still be up to the Fedora maintainers to appropriately triage it

this auto-response is already specific to gnome packages somehow

can confirm. if you choose "Fedora/Fedora/kernel", bugzilla loads a different issue template.

its a bot running post creation.

this is not a special situation for gnome. most packagers understand their responsibility is this initial triage, and forwarding bugs upstream as needed.

right, but they aren't doing that now

ok, might be possible then... but also may need work to have some way to identify those packages, etc...

maybe they just got tired of hearing from users

identify is easy, get the list from the auto-responder script ...

this also isn't fair to other packagers who follow the policy and triage their bugs, to see that gnome is "special" and doesn't have to follow the rules

so, if they dropped this and just ignored the bugs silently, it would make things more fair?

that would be differently bad, not sure if more or less fair

warning users *before* they fill out the bug report would be better than warning them *after*

I still would like to hear from the gnome package maintainers we are talking about

which is why i didn't suggest dropping the auto-response entirely, but adjusting it to be better

one of them responded a few times in the discussion thread

> Can we add a Bugzilla template for bugs filed against Gnome component that encourages filing non-packaging/non-Fedora-specific bugs upstream — yes, I think we should do this.

I meant it would be nice to have them in this discussion in a meeting

I only took over being meeting chair last minute, otherwise it would have been a good idea to invite them ...

agree, we should probably invite the workstation group to an upcoming meeting?

we can look into that for sure, but it is work... it's also likely to be hard to get much help from the bugzilla side these days.

I think any plan involving big changes to BZ workflow is a non-starter. We should be removing our dependence on BZ

until a permanent solution is agreed upon, with the gnome sig participation, could the temporary solution be turning off the auto-response?

I think adjusting of a bug template should be doable.

with the ABRT GUI being gone from F44+ the number of bugs should go down anyway

I just checked. I have no access to templates. It would require bz admins.

And everything else supports issue templates, so it should be easy to migrate those over if necessary

I'm not saying we can't do it, I am just saying it will not be a trivial "oh, just do this". ;)

Brendan Conoboy is the rule owner, he can adjust it

**🔔** reminder: we have spent 15 minutes on this topic **🔔**

(those are **bold** bells, if you can't tell)

the notice yeah...

OK. So I think we generally know what we'd like to happen. 1. Use a bugzilla template. .2. Turn off the autoresponder. Should we vote on this and figure out the implementation plan in some ticket?

this rule also explains the "how" of the rule it seems, it's not the gnome-sig packages but rather a hard-coded list of components

List of packages: 'evince', 'gjs', 'gnome-calendar', 'gnome-connections', 'gnome-control-center', 'gnome-disk-utility', 'gnome-network-displays', 'gnome-online-accounts', 'gnome-session', 'gnome-settings-daemon', 'gnome-shell', 'gnome-text-editor', 'gvfs', 'mutter', 'nautilus', 'seahorse', 'totem' or 'tracker-miners'

bbells

does anybody want to pour ramblings into a voteable proposal?

I think we may want to adjust the wording, but not turn it off.

1 sounds much more complicated, 2 could probably be accomplished today as it doesn't require agreed upon text

Carl George: I don't think we should do 2. without 1.

I mean, we can turn off the autoresponder, but what's that actually going to acomplish

... if nobody looks at the bugs anyways

avoiding pissing off users who files bugs until we get this sorted

just make it less visible that no one is looking

I don't think punting on this issue "until we move off of Bugzilla" is a viable option here.

neither is "do nothing"

We could also just turn off Bugzilla and avoid the problem altogether!

Sorry

proposal: remove the first sentence of the current auto-response

I'd prefer to adjust wording short term and explore the template idea...

> Bug reports for this component on Red Hat Bugzilla are not actively monitored.

I know from personal experience that it will be weeks if not months before we can get the BZ admins to change a template.

the rest is honestly fine

It took three months when we added the template for systemd preset requests

can we put aside the template talk for a bit? i worry it's muddying the conversation.

yeah. that's the "have your cake and eat it too" part.

in my experience, bugs only get activity if QE gets wind of them.

Carl George: the "only be kept open if" part is weird then

+1 to Carl George's proposal

it is, and could use further massaging, but it's fine enough i think

What is the proposal, exactly?

> proposal: remove the first sentence of the current auto-response

sure, +1

And that said first sentence is "Bug reports for this component on Red Hat Bugzilla are not actively monitored."

+1 to proposed

> Please consider reporting your issue directly to GNOME at https://gitlab.gnome.org/GNOME/ to improve the chances that your issue will be resolved. This issue should only be kept open if it: 1. Relates to Fedora packaging or integration with other Fedora components 2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions If this issue isn't needed for either of these two reasons, please: * create an issue with GNOME * add a link to the GNOME issue here * close this issue as CLOSED/UPSTREAM Thank you!

if done, the rest would read:

Agree we can further tweak but let's start with that

The main problem is ignoring of bugs and not templates and autoresponders, but I'm not sure there's a simple solution to the first issue...

fine, +1

It's not really a technical issue

I've got a hard stop at the hour

Sure, +1

+1

i totally agree that is the root problem, but i'm not ready to boil the ocean today

(Which is also not true. They are monitored to some extent, maybe not by the people who are the official maitnainers, and not monitored to the extent and with speed that we'd like. But the same is true for many if not most components in Fedora.)

won't fix the underlying issue but at least the text is better

wooo thanks for counting :)

so we're at (+6, 0, -0)?

We can keep this ticket open and plan to invite the Workstation WG for a later meeting

I disagree with the argument that everyone ignores bugs, so therefore this practice is okay, but I'll stop talking now since this proposal makes the problem at least slightly better

I don't think everyone ignores bugs. I do think that some bugs are ignored for lots of good reasons. (maintainer has no time, they don't seem high priority, maintainer is waiting for some other fix, etc)

I don't think everyone ignores bugs. I do think that some bugs are ignored for lots of <s>good</s> reasons. (maintainer has no time, they don't seem high priority, maintainer is waiting for some other fix, etc)

I don't think 'everyone' does either, but this autoresponder thing is a whole 'nother level of ignoring bugs

probibly we will need to get brendan to change it

and at the end of the day, many maintainers are volunteers, so we can't really tell them what to do. but they still shouldn't boldly proclaim "we're ignoring this tracker"

Carl George: do you consider this enough to consider the ticket you filed as moot?

And maybe also bring up the idea of replacing the autoresponder with a template in the FESCO ticket for further discussion?

(the "many maintainers are volunteers" thing doesn't *really* work when talking about people who get paid for this, but I digress)

well, this?

someone suggested keeping the ticket open until some longer term solution is sorted, which is fine by me, but i'd also be fine limited the scope of my ticket to the auto-response and calling it closed

sorry Timothée Ravier I missed this message.

if mine is closed, someone should file a separate ticket with a better description of what they want long-term

I won't push to keep it open

https://forge.fedoraproject.org/workstation/tickets/issues/131 is a 6 year old ticket so clearly this has been langering for a while

I have not found the courage to read it yet

Proposal: File a new ticket listing the remaining unaddressed grievances, close the current one, to keep things more focused.

I don't think fracturing this into another ticket is helpful but don't feel that strongly

KDE is moving crash reporting to a sentry instance to get something unified accross all distros

alright, proposal withdrawn :)

I don't care too much either way, but if we hope to actually do more here, we should track that

There is a silver lining: migration of issue to the new tracker works great!

But migration of PRs does not, but I digress

But migration of open PRs does not, but I digress

!fesco 3583

● **Last Updated:** 3 hours ago

**fesco #3583** (https://pagure.io/fesco/issue/3583):**changes made to dist-git unused branch - awaiting approval;**

● **Assignee:** Not Assigned

● **Opened:** a month ago by jnsamyak

Was this resolved? or not? Can we just close it? I am not sure I understand any of it any longer.

I have a slightly related topic to bring up here as well.

there will be an open floor after MOOT

I think it's all solved and good.

yeah, I think it's good to close now

!fesco 2966

**fesco #2966** (https://pagure.io/fesco/issue/2966):**request new group aiven-and-friends**

● **Assignee:** kevin

● **Last Updated:** a week ago

● **Opened:** 3 years ago by pwouters

We have been pinging Davide Cavalca and Michel Lind ☘🏖️ until 2026-05-11 on this ticket for almost half a year.

Proposal: Close and re-file once they have an actual proposal.

+1

+1

Yeah that's fine by me

+1

Sure +1

!fesco 3598

**fesco #3598** (https://pagure.io/fesco/issue/3598):**Updates policy exception request for python-manatools**

● **Assignee:** Not Assigned

● **Last Updated:** 19 hours ago

● **Opened:** 3 days ago by ngompa

vote in ticket!

I want to discuss what to do about https://pagure.io/fesco/issue/3119 which was closed two years ago but never actually had the approved procedure applied.

As we are prepping for CentOS Stream 11 to inherit from Fedora, we are again faced with the issue that there are some affected packages that cannot be imported into GitLab (and will probably similarly fail when we move src.fp.o to Forgejo)

huh... I thought it was done...

no it wasn't: https://forge.fedoraproject.org/releng/tickets/issues/11822

Checking object directories: 100% (256/256), done.

Checking ref database: 100% (1/1), done.

$ cd xmltool && git fsck

```

error in commit b18932a97f69d17bd9bc631881197a39f2541b2a: badEmail: invalid author/committer line - bad email

```

Checking objects: 100% (123/123), done.

I was waiting until after Final Freeze to start bugging you about it again

yeah, so just needs doing. ;)

that sounds more like a releng thing to me? fesco already approved this

Yep

Looks fine to me. We should maybe even move the archive repo somewhere else and not keep the branches in the prod repo.

archived branches

Ah, maybe we need them for reference for builds

Let's not open this can of worms. The approved resolution has its reasons.

anything else for open floor?

Yeah

+1 for keeping the agreed as is

Is ball actually rolling on getting more s390x resources for Koji and Copr? I wonder if anybody would seriously getting rid of s390x for everything except ELN and EPEL.

https://pagure.io/fesco/issue/3119#comment-887114 :)

Is ball actually rolling on getting more s390x resources for Koji and Copr? I wonder if anybody would acutally seriously consider getting rid of s390x for everything except ELN and EPEL.

well ... s390x in COPR is 100% ded now right?

It's qemu emulated now

So, there are things going on to get more resources yes...

I fail to see the difference ;)

I have suggested we just drop access to s390x for packit except for "real" builds

that brings the capacity levels back down to what we can probably handle

I'd be fine dropping it myself, but others might not be.

that brings the capacity demand levels back down to what we can probably handle

making the arch Rawhide/ELN/EPEL-only might be a compromise ...

like ... 5 systems?

yes, I plan to limit packit scratch builds after freeze, but that won't solve the problem

to be honest, if we drop it to just Rawhide/ELN/EPEL only, I'd rather us just drop s390x entirely

Can we reduce the set of packages built for s390x?

I'm honestly okay with that lol

but RHEL will wind up with a decaying s390x port over time

I proposed only ELN and EPEL since RHEL for IBM Z is a thing

But Fedora users an maintainers don't seem to care, and it just seems to waste our time

Fedora has done that before and it always comes back because RHEL has to build on s390x

that would basically make all the work shunt to yselkowitz and he would kill us for that

not sure how ELN would fare without Rawhide

That ends up having the same architectural issues as "can we reduce the set of packages built for i686"

It's one of those cases where council input would be useful. It's a political decision to a large extent

s390x is our only remaining big-endian system and as such *does* occasionally reveal real programming errors.

Yeah, I don't think reduction would be worth the effort

So maybe that's the issue we should fix :/

I think that's an orthogonal problem

it should definitely be more discussion than just open floor of a fesco meeting. :)

And limiting to ELN effectively would reduce the amount of packages

there is also a FRCL topic about this, because while s390x is the worst right now, we've had problems with other arches, and we'll have new ones

nirik: agreed

Bc than we would only need to deal with what's in RHEL

there is also a FRCL topic about this, because while s390x is the worst right now, we've had problems with other arches, and we'll have new ones with RISC-V next year

extremely small, last i looked it was something like 0.005%

there's a larger systemic issue to deal with

Happy to open another discussion for this but not sure where that should be

any volunteer to open a discussion topic and / or fesco ticket with actual proposal?

any volunteer to open a discussion topic and / or fesco ticket and / or council ticket with actual proposal?

It's basically us (CoreOS) building s390x just for testing

Contact me at @gotmax:matrix.org: Conan Kudo 🫩 is right, though: if it's not built in Rawhide, the regular maintainer will not care about it and it will only be dealt with by the ELN SIG.

discussion or devel list ?

no one uses FCOS on s390x

Which right now is basically 1.5 people.

Which right now is basically 1.5 active people.

I already did at the FRCL level, I'd rather wait until that concludes

fair point

anything else for Open Floor? because I forgot NWC :)

Did anyone end up reaching out to the Deepin DE people?

I'm supposed to I think? But I haven't since I have been traveling since then

yup

just let us know when to start the 4 week clock

I'll do it once I'm back home at the end of this week

Thanks

I should be able to take the chair next week.

do we want to invite Red Hat Display Systems team / WSWG people?

i was off by a _zero_, last countme reporting period s390x was 451 systems out of 764,541, making it 0.05%

i was off by a _zero_, last countme reporting period s390x was 451 systems out of 764,992, making it 0.05%

451 is more than I expected.

it's a pretty hot temperature if you are a book.

Burn it with fire!

Context for this question?

followups for !fesco 3568

people wanted to invite people so I'm asking if we should ... actually do that

Yeah, I think we should do. It'd be good to have a more interactive disucssion.

"interactive" is one way to put it :D

I see no "no"s so

I'm going to close meeting in a few minutes unless there's something else.

Thanks folks

Thanks Fabio!

thanks Fabio Valentini

siosm gave a cookie to decathorpe. They now have 163 cookies, 1 of which were obtained in the Fedora 44 release cycle

yselkowitz gave a cookie to decathorpe. They now have 164 cookies, 2 of which were obtained in the Fedora 44 release cycle

Very fresh cookies!

yeah. so think I've chaired enough for this year ;)

fresh out of the kiln

decathorpe gave a cookie to siosm. They now have 63 cookies, 8 of which were obtained in the Fedora 44 release cycle

thanks everyone for coming (and staying for 90 minutes), see you soon