Meeting started at 2025-11-25 17:02:25 UTC

The Meeting name is 'FESCO (2025-11-25)'

!group members fesco

The Meeting Name is now fesco

!hi

Fabio Valentini (decathorpe) - he / him / his

!hi

Fabio Alessandro Locati (fale) - he / him / his

!hi

!hi

Zbigniew Jędrzejewski-Szmek (zbyszek)

Neal Gompa (ngompa) - he / him / his

Hmm, seems like we might be short today too.

this is US Thanksgiving week

so that might be why

It's a holiday for you and you're here!

I almost wasn't

!hi

Michel Lind (salimma) - he / him / his

OK, we have quorum.

Conan Kudo: there was a question about %buildrelease on the mailing list. You're probably the best person to answer that.

I'll answer there

the answer right now is "probably not"

!fesco 3496

Yeah, thanks.

!fesco 3496

● **Opened:** 3 weeks ago by amedvede

● **Last Updated:** 4 hours ago

**fesco #3496** (https://pagure.io/fesco/issue/3496):**Request to Authorize Removal of upstream source files from commit history for adobe-source-han-mono-fonts package**

● **Assignee:** Not Assigned

(the bot still doesn't like too many commands in one message)

!group members fesco

Members of fesco: Dave Cantrell, Fabio Valentini, Fabio Alessandro Locati, Tomáš Hrčka, 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, Zbigniew Jędrzejewski-Szmek

Ah, shit, indeed.

So the first topic wasn't set properly.

Too late now.

🤷

I was tricked by the fact that it threw an error when I first pasted things, so I split it up, and when it didn't complain, I didn't look closely.

the topic worked, the !group call didn't.

In https://pagure.io/fesco/issue/3496#comment-993193, Stephen Gallagher made a proposal

zodbot is feeling the holiday season as well, proabably

anyway. what *is* the process for "we can't legally distribute this content" right now if it's not *this* process? ...

> Revision of the git history for any other reason must be submitted as a FESCo ticket for consideration.

>

> Releng is empowered to follow its branch rewrite policy if one of the following conditions are met:

>

> The checked-in file exceeds 1 MiB in size and is either a) unused or b) exists in (or is moved to) the lookaside cache.

> The checked-in file includes content whose redistribution status is either impermissible or indeterminate (including, but not limited to: an unacceptable license or patent-encumbered content)

!hi

Stephen Gallagher (sgallagh) - he / him / his

(I am only partially here. On my phone on PTO)

nirik's comment makes it sound as if the process for removing legally problematic content is actually a different SOP, in which case I agree that removing point 2. from the proposal makes sense

So I'd be inclined to merge this. If we think that something so egregious is in the history that this process is not enough, then we can have a separate discussion.

that too.

fine with me

let's do it

I guess it's fine

did legal already weigh in on this?

they won't

seems weird if we're the ones adjudicating legal claims

OK, we have zbyszek, fale, sgallagh, decathorpe +1, kevin -1 in the ticket.

there's also not really a reason to, since the SOP for legal is different

(and the legal stuff is _usually_ how you get the badge)

(and the legal SOP is _usually_ how you get the badge)

ugh, so be it then. I guess people who really want to can... download the SRPM from old releases?

usually if it's severe enough, we blow it out of the master mirror

it replicates the deletion everywhere

My intent with how it was written is that whether or not it is permissible is decided elsewhere.

Stephen Gallagher: should we maybe extend the last sentence to say that a separate ticket should be opened if the SOP is not enough?

Does it not already say that?

No, it says "for other reason". But I mean more "in a different way".

I don’t understand the distinction

the reason would be the same, but the outcome would be different (i.e. not only rewriting the existing branches and keeping copies as backups, but rewriting *period*)

the reason would be the same, but the outcome would be different (i.e. not only rewriting the existing branches and keeping copies as backups, but rewriting _period_ without backups)

The current proposal implies that there's one way to revise git history, and that is the branch rewrite policy of releng. And we here discuss when it is OK to invoke this without a FESCo vote. But problem with that is what Fabio wrote, that we want a different method to be used.

Without public backups, maybe. Records retention laws might require us to keep private backups anyway

Sure, but the whole point of the current SOP is to allow interested parties public access to full history. We might need/want a way which does not allow this.

Ok, I see the distinction now. I’m not sure we need to state it though.

“File a ticket with FESCo” is the default expectation when an explicit rule doesn’t exist.

we probably don't

OK, so if that's the consensus, then folks who didn't vote yet please cast a vote.

that's Michel Lind UTC and Conan Kudo if I'm reading the log correctly

just did +1 in the ticket

I did +1 here I thought? ok, not explicitly, so +1

Michel Lind UTC: "I guess it's fine" is not enough1

Michel Lind UTC: "I guess it's fine" is not enough!

Stephen Gallagher: typing?

No?

Matrix bug

!fesco 3512

!fesco 3512

● **Assignee:** Not Assigned

● **Last Updated:** 5 hours ago

**fesco #3512** (https://pagure.io/fesco/issue/3512):**Let's do something about ignored CVE bugs**

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

This is annoying.

looks like everyone is just fed up with low quality of the reports? :D

making the exercise of "count how many open security issues we have" kind of pointless

Can we get the RH team that files the bugs involved in the discussion?

I don't want to talk about this topic

because it's just depressing and annoying

Because that seems to be where the problem starts…

and we can't do anything about the bugs

I think it would be a rational thing to ask for if maintainers were paid to maintain the packages. I do not think it can be a reasoable request for volunteers

if Fedora had a way to pay maintainers, that would be cool... :)

I asked for that in the ticket

Yes, that's where I got the idea ;)

because I replied once to the person who ran it after he tried to do the non-responsive maintainer process on me

and then nothing changed

These tickets are a large part of what burned me out for Node packaging.

I'm nearing the deep end for some things because of it

and that new website is super not helping

oh even if maintainers are paid, e.g. if something like this happens at work I think the team that spams other teams will get in trouble

For a while, I was just closing them all as WONTFIX in protest

for wasting valuable time

I don't think we'd lose much of substance if those ticket stopped getting filed tomorrow. And that's not a great state for things to be in

yeah it got worse over time. it used to at least have guides for setting severity on the submitted update. now it doesn't. and no detail unless you click to the linked bug

I definitely want an opt out so e.g. some of my packages should never ever get nodejs bugs ever

(they should scan compiled artifacts and not just the source RPMs)

I kind of don't want anymore ffmpeg security bugs

because of how many wrong ones I get

I'm practically flooded with them

yeah doesn't help that tickets are filed for security issues that *have already been addressed* (sometimes years ago)

Should we get Jef Spaleta involved? We can at least have a discussion about the accepted severity level for this process

That'd be great. Is Jef Spaleta listening?

probably not ... let's move that to the ticket and move on?

I think those are two different issues: even if the CVE reports would be awesome quality, I think it would still be not reasonable for a volunteer maintainer to act on those CVE in 6 weeks or be tagged as unresponsive

OK, and what about stuff like "QtWebKit is full of hundreds of known CVEs. Please remove this package as soon as possible"?

!bug 1711519

RHBZ#1711519 (https://bugzilla.redhat.com/1711519): [qtwebkit]: QtWebKit is full of hundreds of known CVEs. Please remove this package as soon as possible

I would separate the topics of whether this bug even needs to be filed, from whose responsibility is to resolve it and under which SLA

I mean, I think the web is a mistake so sure, but that will mean we don't produce a usable distro

If we don't solve the first, the second is not worth trying to be solved

so if some security team takes security really seriously and expects an SLA, how about this

if they produce a working PR, the maintainer should merge it or ... we already have a fast-track non-responsive process to get the PR merged

Fedora KDE SIG has been trying to strip out qt5-qtwebkit deps in our chain for some time, but this is for qt4-qtwebkit... I don't even know wtf is going on there

or security team members can apply for proven packager status, that's a reasonable request if they have a track record

> security team members

first step would be to define this group

because I don't think it exists

it doesn't

there used to be one a long time ago, but it's been defunct for many years

I don't think we need to define the group. Privileges in Fedora are attached to people, so a person can just start working on this. We don't need a group.

we also have no Fedora representatives for the linux-distros@ list either

Anyway, looking at the #1711519, I think we should put the foot down and drop it for F44.

I'm fine with that

it → the package

I literally could not possibly care less about qt4-qtwebkit

having a SIG that acts as an intermediary between CVE / Red Hat and the bug tracker would be worthwhile though I think

and it would open the door for external representation for the security handling

which, again, we don't have

Well, if we had CVE issues filed for Fedora reliably, so that the number of open CVEs would actually mean anything, we could then use that number to start conversation about security team, funding, need for resources and so on.

there is talk of resurrecting the security SIG. I don't think it ever got off the ground

bookwar: have you seen the cve website that was made?

bookwarwould the first step be to *stop* filing the current CVEs

I'm unhappy it exists, but it's now a thing

Conan Kudolink?

I haven't seen the site. Can somebody post a link?

I haven't

I was informed of its existence this morning

(as noted in the ticket, we tried looking at our CVEs in EPSco and people get discouraged by the false positives after a while - I think we fixed a bunch of the real CVEs in the first few weeks, then ... we drowned in false positives)

this uses the Fedora logo etc. so... this is an official site?

or it's presenting itself as such

I don't know

I'm the only non-Red Hatter who was emailed about the site

lol it 1) doesn't say who's running the site, and 2) it says the site is open source but it doesn't link to the sources 🙃

"Fedora CVE Dashboard is an independent, community-driven project. We are not affiliated with, endorsed by, or sponsored by Red Hat, Inc., The MITRE Corporation, or any other trademark holders mentioned above. "

> Fedora CVE Dashboard is an independent, community-driven project. We are not affiliated with, endorsed by, or sponsored by Red Hat, Inc., The MITRE Corporation, or any other trademark holders mentioned above.

and it's being run by Red Hatters

bookwar :)

so overall, I'm unhappy about it

I am a redhatter, it doesn't mean i get any info about it. Looks like someones personal project so far.

Is using the logo allowed by the policy?

no

Not a bad project, but needs someone to show up and talk about the goal the tools , the approach and so on

I think the website is nice.

if this is done without trademark approval... idk, sounds like something that could be problematic

should we raise this with legal :P

Yeah, I think we should, based on the general principle of protecting the logo.

I don't object to something like this existing if done responsibly. given the trash that is the CVE reports now this seems dangerous

ok who wants to take the bullet and email legal?

I don't think we need to fight against the site. It is just analytics, and a good one. I'd rather invite the person who created it, to talk to us, and to discuss next steps.

at least right now it would probably be food for people who want to post misleading youtube videos about how Fedora has thousands of open security bugs

bookwar: yes

intention is one thing. that they broke trademark laws and intentionally or not make us look really bad because the data is garbage...

I would have preferred they not launch the site, have the code public, and talk to us first

Well, we do have thousands of CVEs open. So the website is not the problem.

do we?

we don't know

the site is public, the code is private, and they surprised us with an 8:30am launch

given the dumpster fire quality of the cve reports, I don't think we can tell

I will note that just this week I stumbled upon open bugs that should have been closed because the maintainers who made updates didn't link the bugzilla

We have 6613 bugzillas that match "CVE"

I don't even know how they are collecting the bugs

Right. I don't really like the fight against the person who brought the data as the only outcome of this conversation :)

which means exactly *nothing* :)

bookwar: so my intention certainly wasn't to fight against the person. Nevertheless, they should not use the Fedora logo for a 3rd party site. This just creates confusion.

It's a data point. We can try to interpret that data point, but we should not fight against it being a data point.

Especially that the domain name has "fedora" and ".org" in the name.

it's a low quality datapoint

which is worse than no datapoint

Anyhoo, what do we do here?

let's not repeat that fedoracommunity disaster which we had couple of years ago though

... we owned that domain though, that was a different mess

We've been 20+ minutes on the topic.

We have the original ticket (about bugzilla) and then the discussion about the site.

Anew proposals for action?

*Any proposal for action?

can any RHer here bring someone from ProdSec to us to discuss things?

I think that's the only meaningful action item for right now

(well, and figuring out the trademark thing)

(well, and figuring out the trademark thing for the fedoracve website)

let's !action jef

(well, and figuring out the trademark thing for the fedoracve website)

... will Jef Spaleta be able to do it?

we can technically do that, but it doesn't mean it'll be done

maybe just ask the owner/maintainer to apply for official trademark use?

I can go ahead and reply to them accordingly about the trademark thing

then have the discussion in context.

but the prodsec thing is out of my realm of capability

Good?

If no objection, I'll move to the next issue.

someone needs to talk to Jef though right

but otherwise yes

Yeah, I'll CC him on the summary.

!fesco 3507

!fesco 3507

● **Last Updated:** 4 hours ago

● **Assignee:** Not Assigned

● **Opened:** 5 days ago by bookwar

**fesco #3507** (https://pagure.io/fesco/issue/3507):**FESCo election policy which prioritizes first timers**

(FYI, that website will go viral once we post this minutes)

(FYI, that website will go viral once we post this meeting minutes)

***fun***

Streisand effect? :P

bookwar: I think the issue you raise is valid.

I still think that having a "junior" member is a bad way to address this

I'd rather see limits like "not allowed to run if it would be your 3rd consecutive term"

yeah

2 on, at least one off seems reasonable

I would think we could all use the break after two.

I do not like term limits , because I think setting them means making a rather risky bet on the expectations from the community, and it may lead to disaster in case it doesn't work. The approach I suggest is much safer and less disruptive, even if we will have a complete stranger somehow appearing in FESCo for one season.

it also won't work for us

I also think that consecutive terms limits is way better than junior members

for the same reason it causes problems for openSUSE

Conan Kudo: what won't work?

term limits

On the other hand, if FESCo itself will continue to refer to my proposal as a "pity seat" or a "junior" or whatever, then the proposal will not work even if we approve it. So for me the question is mostly do I have a chance to change your minds or not. :)

we're not saying someone can't serve again, just that they need to take a break first

bookwar: you raise a very good point.

yeah, but it doesn't work, because the underlying problem is people don't feel comfortable to stand up in the first place

I suggested in the ticket that for the transition, we don't make the entire fesco incumbents force-retire but phase it in gradually

for the past few election cycles, there have always been more candidates than seats - so I don't think this would be a problem

this time around we have at least 3 new participants... but it is true we can not assume that there will always be people ready to propose themselves

I like bookwar's idea of a bucket of ranked voting

the alternative I thought of but hesitate to suggest is to say the first-timer seat is only available if there are competitive candidates (for some measure of competitiveness)

let's assume there's not enough candidates, then we could just drop the term limit

not necessarily calling them junior

e.g. if there's only one first-timer in the race, and they didn't win outright, they can't use that to get a safety seat

The thing is - we should not just have a process, we should have a call for new folks that we want them here.

It is part technical, part marketing thing

having at least one seat that have a weight for new people each cycle

having at least one seat that has a weight for new people each cycle

I see that support in most every election already honestly.

what ranked voting? we don't really have ranked voting yet right?

I'd love ranked voting rather than approval voting

our system is ranked voting

our system is RCV

bookwar: I was no looking at the fesco voting results. The problem I see is that the ranked results are very stable. E.g. if you compare F42, F40, F38, the highest three positions are fairly stable, and some movements starts below that.

but bookwar proposes that we extend it by having a weight where one seat prefers the highest ranked new person

that still smells iffy to me

Yeah, but that would would always kick out on of the people who are above the threshold, and those are actually most often the people who haven't been long on fesco or are completely new.

it formalizes something that i think we already encourage and that seems, beneficial to me.

In that regard, I think term limits would be better, because it'd introduce a shuffle among all positions.

right. so making the most senior person retire temporarily is better. though if they come back they might knock out the new-ish member again

I think the term limit seniority currently is Kevin, Stephen, Zbyszek.

I think that the limit does also identify a good way to mitigate burnout as well, but it wasn't the original idea.

I also would be in favor of just adding more slots to increase the range

but that could lengthen our meetings and make quorum more difficult

Yeah, before every election I wonder if it's time to not run again… A break would probably be good.

I took a break for 6 months a while ago, it was nice

I would be -0 / -1 to adding more folks. We have trouble reaching quorum already, and full meetings are rare.

it also makes scheduling more difficult (it's difficult enough as it is, I have a permanent conflict with an important internal meeting now that DST is over)

I do the similar thing for Council elections each time, and it bothers me that I have to do that decision during the nomination time based on personalities of folks in the queue for the upcoming election. This feels weird, personal, and way too involved. So one of the goals was to free myself from that personal choice, where I do not to question - should I free my seat for a newcomer, rather I should ask - do I still have the energy to run myself. The newcomer will get their seat anyway independently from me.

I haven't proposed the simular policy for Council because Council has only two elected seats and much bigger trouble with finding possible candidates. FESCo does seem like safer environment for this to try.

hey we're looking at improving representation on fesco so that it's not always the same 8 people, here's three options we're thinking about:

1. reserving one seat for a candidate who runs for election for the first time

2. limiting number of consecutive terms for fesco members"

because I don't think we're going to find a solution here today

what about posting something on the discussion site to the effect of "

sorry, off-by-one-error. counting is hard

sure

keep in mind that one seat reservation each cycle means two new people each year, so that's an important note

Also add "3. Other ideas" and that sounds good to me.

ha ok, I got volunteezed

Right, you made a proposal

I'd suggest putting the recommendation we prefer first on the list, but yes, eitehr way we should involve the list

Yeah, I think we need a wider discussion. The problem with a limit on consecutive terms would immediate kick out all of fesco. We might want to stagger how that is introduced.

ha ok, I got volunteered

true

"if it affects more than 2 current members, this is limited to the 2 longest-serving members" or something to that effect, maybe.

please include that in the mail ;)

2 longest-serving members unless others volunteer

this addendum makes sense, even more for the beginning

Yep.

+1

!fesco 3506

● **Assignee:** ngompa

● **Last Updated:** an hour ago

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

**fesco #3506** (https://pagure.io/fesco/issue/3506):**Change: BtrfsBootForCloud**

bookwar: thank you for coming and the discussion

+1 no notes approved move on?

(sorry, getting hungry)

Fabio Valentini: I don't understand

davdunc: thank you for coming

zbyszek: I only wish I was here more frequently.

*were*

FWIW I'm also here

it's a long meeting, I'm hungry, and I want to move on ;)

Jeremy Cline: thank you for being involved in the discussion too ;)

Fabio Valentini: the current tally is (+1, 0, -1). Unless you mean something else…

no, I mean: hurry up, man :P

After reading Neal's latest comment, the listed goal can be achieved quite a bit more cheaply with much easier methods.

so I was waiting to hear of David Duncan's usecases before voting

but I am also curious how the BLS was updated and who get to decide on the new standard

So was I, but I didn't want this to get autoapproved…

I want to use the btrfs-send for differential updates in digital twins.

"digital twins"?

I was about to throw a procedural -1 :)

Michel Lind UTC: think shadow devices or devices that are updated infrequently, think edge.

ah gotcha, so they periodically get synced

and authenticated btrfs data is easy to verify for synchronization

so - similar use case to Fedora workstation too, where you can't get a complete snapshot unless /boot is also a btrfs subvolume?

specifically, yes.

yes

trained models and related service volumes.

davdunc: I think we have the wrong format for such discussion here. A long format it needed. But in short: replication of systems always needs to be *not* copy some things, e.g. machine-id, random-numbers, other state. So some "smarts" as to what is copied always need to be implemented. Extending those smarts to copy a kernel into the right place at the right moment is necessary for other reasons too. So I don't think this use case is a convincing reason to do the proposed change.

at the same time, your reason isn't exactly a good justification either

we have already another variant of the cloud image that does maxi-ESP with UKIs

zbyszek: of course.

how about a middle ground?

and I'm not interested in chasing down all the providers again about the bugs related to large ESPs

make this a new variant that has btrfs on /boot, in addition to the current layout

*layouts

if it turns out to be the most popular then the users have spoken

I mean... we _can_, but why? the existing one uses ext4

if it unblocks this discussion

Did you see my answer to this question in the discussion thread?

so we'd be doubling all the images for cloud then

rechecking. it's been a long day

yes. I don't see the failure in having them both and I imaging that there won't be a compelling reason to mix them when given a choice.

imaging*

Just make it the generic cloud image? Replicating a GCP image with its agent and all that to somewhere else doesn't make sense to me.

tbh, if we did that, I'd probably make the ext4 boot one the singular one like we did the UEFI-UKI one

rather than the btrfs boot one

I could go for that Jeremy Cline

I think there's a cost to having multiple partitioning layouts. We have lots of trouble just doing QA on the ones we have. If we make another one, if we spend enough time to make it work, users will probably use it. But that's not a good test. We should figure out what we need, how to achieve it most simply, and not duplicate work.

sorry, I really need to drop off now. I explicitly *don't* volunteer to run next week's meeting btw

the reason we don't have flavors for UEFI-UKI is because the drivers aren't there and there's no support model for custom instance types

And to clarify, I mean just make a generic cloud image variant with it

I guess what it does not answer is, "who are the current maintainers" but we can continue that on Discourse

I don't think it makes sense but at least it doesn't impact me

I have a hard stop soon too

if we can't conclude this today can we continue elsewhere? it probably was brought up prematurely anyway

and unfortunately all the topics today ran long

Yeah, I think further discussion would be good.

davdunc: do you want to post a more detailed description of your use case in the bug? I think it's useful to have concrete usecase to discuss.

i will do that zbyszek

salimma gave a cookie to davdunc. They now have 45 cookies, 1 of which were obtained in the Fedora 43 release cycle

davdunc++ thanks

zbyszek gave a cookie to davdunc. They now have 46 cookies, 2 of which were obtained in the Fedora 43 release cycle

fale gave a cookie to davdunc. They now have 47 cookies, 3 of which were obtained in the Fedora 43 release cycle

I closed like 8 tickets when preparing the agenda today, so I'm ready to take a break.

A volunteer is needed.

I recently did it, but if there are no takers, I can do it next week

I can't chair until the meeting conflict is resolved

so hopefully either the work meeting moves, or this meeting moves after the next election

Fale: thanks

If there's nothing, I'll close in a minute.