Meeting started at 2026-05-19 17:01:21 UTC

The Meeting name is 'FESCO (2026-05-19)'

The Meeting Name is now fesco

!group members fesco

Members of fesco: Dave Cantrell, Fabio Valentini, Máirín Duffy, Fabio Alessandro Locati, 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

morning

!hi

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

(we should update that template so we stop pining dcantrell

Neal told me he won't be there

hum, isn't that a group?

yeah, could be. let me check it.

https://accounts.fedoraproject.org/group/fesco/

yep, this one needs an update

yeah, I thought Stephen Gallagher updated it, but will do so now.

done

!hi

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

!hi

zbyszek: Zbigniew Jędrzejewski-Szmek (zbyszek)

!hi

Michel Lind ☘ UTC+1: Michel Lind (salimma) - he / him / his

5 we have quorum

Sorry, I added fale and forgot to drop David

!hi

Fale: are you there?

He said !hi above.

Yes 🙂

We only have one topic for today

!fesco https://pagure.io/fesco/issue/3409

Oh, indeed.

No reproducing during FESCo meetings, please. It's unsanitary.

I see you are too old to get that reference :D

Fabio Valentini (⛱️ ➡️ ❓): If I could reach you with my cane, I'd smack you with it! Whippersnappers.

So the deepin maintainer is not responding but it keeping his packages when they are orphaned

So the deepin maintainer is not responding but he is keeping his packages when they are orphaned

yes, appears to be active but generally non-responsive (and emails to the address on file seem to bounce too)

https://src.fedoraproject.org/rpms/SwayNotificationCenter/pull-request/1

Email bouncing is also covered under Nonresponsive Maintainer Policy now

so, perhaps we need to retire them at this point.

It seems that and the https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#revoking process Fabio mentioned would have functionally the same outcome

nirik: Right, but apparently they've been retired previously and the maintainer simply unretires them without resuming maintenance.

hum, how can they do that, if they are actually retired it should take a releng ticket/process to unretire them

Should I write a comment in their fresh PR?

you mean that they were orphaned and they just take them right?

pointing them to the issue in fesco?

Ah, maybe the tickets really mean "orphaned", not "retired"?

!hi

Máirín Duffy: Máirín Duffy (duffy) - she / her / hers

(sorry im late i had an urgent matter)

Sounds like they should be non responsiver

👋

Sounds like they should be non responsived

The problem with nonresponsive is that they can still go ahead and pick up the orphaned packages again

And we don't have a process for hostile packagers yet

I hope everything is okay now?

should we add a cool down period of a packager that was deemed unresposive to take on his "old" packages?

https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#revoking was mentioned

Which is why we're talking about skipping past "orphan" and going straight to "retire"

But that is a very big hammer

Yes! It's settled

But that (revoking pollicy) is a very big hammer

It doesn't require maintainer sanctions, but if they REALLY want to bring it back, it'll require a releng ticket and/or a new review

We also lost track of who sponsor whom but I guess FESCo can decide to be the one unsponsoring

When a package is unretired, this is done through a releng ticket, right? Can we ask releng to _not_ process those packages if the request is made, as a special case?

We don't have any realistic way to implement that policy programmatically, so it would be inconsistently enforced. That's probably worse.

I think retiring is probibly the best way forward. Other means could be not clear whats going on.

Ok I have another solution

Add it to the list of retired packages that can't be installed

yes. We can also add a link to the fesco ticket in the retirement message

We can ask releng for anything! (And often do...) I'm sure they'd be fine with that.

That's a big hammer; it's *possible* that another packager will opt to unretire and take over maintenance.

I'll be afk for a while it it's alright, there's a layoff pizza party and I'm in danger of missing out on pizza

yeah, but then they are still building it and we are composing it, etc... and they may not even know it's not installable for a while and may have a hard time figuring out why

I'll be afk for a while if it's alright, there's a layoff pizza party and I'm in danger of missing out on pizza

gather ye pizza while ye may

Leave no slice uneaten.

"retire and ask releng not to un-retire" seems like a middle ground that's not as bad as revoking packager group membership

yeah

though it does just shift the problem off DDE packages onto other things maintained by the same person ...

i don't fully understand the problem

orphan package limbo?

Fabio Valentini (⛱️ ➡️ ❓): Based on their level of activity, it seems like they DO care about their other packages though

Stephen Gallagher: not enough to respond to package reviews

I think there's a toddler to automatically handle package unretirements now but not sure if it's been deployed yet

That might require updates

Máirín Duffy: Maintainer hasn't been keeping the Deepin stack up to date and it has known serious vulnerabilities. Prior attempts to orphan the packages so someone else might take them over has just resulted in the maintainer appearing just long enough to thwart the non-responsive process.

it has been... not quite announced yet tho...

Do we handle lack of security issue handling separately from buggy / doesn't work

What about the following as a proposal: retire all packages in the list, with the message mentioning the fesco ticket. Ask releng to not unretire those packages if a request is made, unless they passed review again.

And if further action is needed, handle that separately.

Alternative, 3 strikes and youre out

It's not just about security, the deepin desktops package don't work / don't build anymore.

In addition to the re-review requirement, should there be something about the serious security issues that prompted this whole thing? Were those ever resolved upstream?

+1 to zbyszek

I feel like policy for security concerns could be stricter

+1

gotmax23: I think they were addressed to some degree, but maybe not comprehensively. Neal would know more I think, since this was an issue in OpenSUSE too ...

unclear, but that should be part of re-review...

forcing them thru a new review makes sense

+1 to zbyszek's proposal

+1 on zbyszek proposal

+1 to zbyszek's proposal as well

gotmax23: IMO a reviewer should look at security posture too. If a package was retired also because of security issues and the reviewer approves it without checking that the know problems have been addressed, they are negliegent in the review.

I don't think security issues are part of the package review checklist at all

it would be good to add them

There's a lot of things that a reviewer *should* do, but they key word is should

There's a lot of things that a reviewer _should_ do, but the key word is should

No, but "is this the latest upstream release" is

Which covers a lot of that.

No, but "is this the latest upstream release?" is

Máirín Duffy Any objection? Only your vote left

Timothée Ravier: no objection, I thumbs up

Máirín Duffy: Protocol is for an explicit "+1" comment to be clear.

And so it makes it into the logs

It's unclear if the latest release actually fixes the issues. IIRC the Opensuse report mentioned a lot of cases were a release fixed some issues and then introduced new ones. But I guess we can cross that bridge...

+1 from me to proposal

It's unclear if the latest release actually fixes the issues. IIRC the Opensuse report mentioned a lot of cases where a release fixed some issues and then introduced new ones. But I guess we can cross that bridge...

In this case, sure. But in general, it at least means that most known vulnerabilities are addressed.

will someone take the action to do the retirements? :)

I can

kevin gave a cookie to gotmax23. They now have 59 cookies, 1 of which were obtained in the Fedora 44 release cycle

hold a second

the proposal was to "retire all packages in the list", the approval says "packages maintained by the deepinde-sig" - these are not equivalent

sgallagh gave a cookie to gotmax23. They now have 60 cookies, 2 of which were obtained in the Fedora 44 release cycle

ah yes, I tweaked that to be more precise

but you're right that I should not have done that

I don't think it should be all packages owned by the SIG. It looks like there's some not explicitly deepin things in there

How about `*deepin*` packages?

Wasn't the list mentioned the one in https://pagure.io/fesco/issue/3409#comment-1005244 which is what I wrote?

scroll down

there's four deepin packages *not* maintained by the SIG

arg

myu bad, sorry

And golang-github-linuxdeepin-go-x11-client

my bad, sorry

Hence my `*deepin*` suggestion

that doesn't cover `*dtk*` (deepin toolkit?)

"the list" (assuming it was referring to the [the two tables here](https://pagure.io/fesco/issue/3409#comment-1005244)) was fine

ok, le me redo the agreed as proposed

as I should have

thanks

I can do it, if there are no other volunteers

I'd like to mention something I note every once in a while... we have a lot of sponsor requests sitting around. ;( I know sponsors are busy, but it's sad.

https://pagure.io/packager-sponsors/issues

https://pagure.io/fesco/issue/3601 also needs to be processed

It was technically approved 2 weeks

It was technically approved 2 weeks ago

oh yeah.

whoops, I missed that one. I can add it to today's email

Thanks

also /me waiting for two of my Change proposals to get processed ...

Fabio Valentini (⛱️ ➡️ ❓): With Summit last week, I think a bunch of stuff got dropped on the floor

But with Aoife Moloney back on the job, I am sure things will start flowing again

Hum, I had not processed it as I hard though it was not old enough

did I miss something?

I guess at this point we just remove them and orphan all the packages and interested parties can just take them?

Nonresponsive tickets are autoapproved after three days as long as there's one +1 and no -1s

Timothée Ravier: It passed 14 days with at least a +1 and no -1s, so yeah, it is approved.

When Miro used to process them, he'd give the packages to co-maintainers who asked for them first

Oh, I forgot non-resp has a different policyt.

But it would have been approved under either

ok, I think I can do that yeah

Oh, I forgot non-resp has a different policy.

I think there was a discussion about this and it started being done like this because co-maintainers were unhappy when other people picked up packages that they were already maintaining

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#steps

yeah, true. first come first served.

anyhow, can do it

If at least one FESCo member votes +1 and no one votes differently, the ticket is approved after three days.

ok

I think there's some scripts in the releng repo to do all this already

For the last couple nonresponsive tickets I filed releng tickets so it didn't have to always fall on you

But I was waiting for this one for it to be formally approved

yeah, lots of releng is out for ptos/etc... but thats fine. I can process it.

gotmax23 gave a cookie to kevin. They now have 800 cookies, 15 of which were obtained in the Fedora 44 release cycle

sgallagh gave a cookie to kevin. They now have 801 cookies, 16 of which were obtained in the Fedora 44 release cycle

yselkowitz gave a cookie to kevin. They now have 802 cookies, 17 of which were obtained in the Fedora 44 release cycle

gotmax23 Feel free to ping me if things need a small nudge like that and I missed it

siosm has already given cookies to kevin during the F44 timeframe

Alright, I'll close this one if there is nothing else

Timothée Ravier: thanks for chairing

decathorpe has already given cookies to siosm during the F44 timeframe

gotmax23 gave a cookie to siosm. They now have 64 cookies, 9 of which were obtained in the Fedora 44 release cycle