search

flathub-infra / flatpak-builder-lint

A linter for flatpak-builder manifests
MIT License
50 stars 126 forks source link

Exclude org.gnome.Calls from automerge #412

Closed darkdragon-001 closed 3 months ago

darkdragon-001 commented 3 months ago

This has been in place since over two years.

Without the auto-merge feature, the maintenance effort will be too high for me and I will step down as maintainer of this package.

bbhtt commented 3 months ago

"maintenance effort will be too high" is not a good reason. "Predates the linter rule" is only for the ones that we grandfathered in.

If you have an actual need please add it in the exceptions.json.

hfiguiere commented 3 months ago

maybe updating less often. Like when the app is actually updated. Instead of the frillions of automatic updates. Automatic updates are not for "YOLO no testing".

darkdragon-001 commented 3 months ago

There has not been a single breakage introduced in this package using this functionality, yet a lot of security vulnerabilities have been fixed using the auto updater. Why is that? Because this is how most Linux distros work: Libraries are updated independently from the applications. I am refusing to ship packages with known vulnerabilities.

bbhtt commented 3 months ago

I am refusing to ship packages with known vulnerabilities.

What component has current known vulnerabilities here? Can you please explain? If there is a legitimate need to keep some security sensitive modules updated, I'm ok with automerge being enabled.

yet a lot of security vulnerabilities have been fixed using the auto updater.

Lot is probably an exaggeration. The only component that is security sensitive seems to be sofia-sip (which had 6 CVEs in total, 3 after enabling auto merge). I don't see any security issues reported in the past or recently for rest of the modules.

bbhtt commented 3 months ago

Also you shouldn't have jumped to mark it as EOL just because you didn't get an exception immediately. Nothing stopped you from manually merging the PRs opened by flathubbot or stepping down. Let's not rush to a decision here that will confuse the users.

There are at least 3 other individual maintainers https://github.com/flathub/org.gnome.Calls/collaborators > Outside collaborators and flathub/gnome is also the maintainer of the app.

darkdragon-001 commented 3 months ago

I am refusing to ship packages with known vulnerabilities.

What component has current known vulnerabilities here? Can you please explain? If there is a legitimate need to keep some security sensitive modules updated, I'm ok with automerge being enabled.

There are 12 library dependencies. Each of them can contain security vulnerabilities and a single one can be enough to gain permanent access to devices even if the vulnerability is closed later.

yet a lot of security vulnerabilities have been fixed using the auto updater.

Lot is probably an exaggeration. The only component that is security sensitive seems to be sofia-sip (which had 6 CVEs in total, 3 after enabling auto merge). I don't see any security issues reported in the past or recently for rest of the modules.

3 CVEs fixed by auto updater sounds like a lot to me.

Also you shouldn't have jumped to mark it as EOL just because you didn't get an exception immediately. Nothing stopped you from manually merging the PRs opened by flathubbot or stepping down. Let's not rush to a decision here that will confuse the users.

I don't have the time to merge PRs manually. Burnt out maintainers is a real problem and I have to protect myself. To me it feels reasonable to mark an unmaintained package as EOL as nobody will make sure it is safe to use this app.

There are at least 3 other individual maintainers https://github.com/flathub/org.gnome.Calls/collaborators > Outside collaborators and flathub/gnome is also the maintainer of the app.

I don't have access to this page but there hasn't been a single PR from someone else than myself, flathubbot or dependabot.

bbhtt commented 3 months ago

Ok, but please don't EOL maintained software. It's essentially a large warning for users and causes too much confusion.

If you don't want to be involved you could've asked to step down/be removed like you did here https://github.com/flathub/flathub/issues/5355. We have a tracker issue pinned in flathub/flathub for orphaned packages in need of new maintainers too.

I've reverted the EOL PR for now, I'll ask if anyone from upstream is interested in maintaining this. If not we can EOL it.

bbhtt commented 3 months ago

Since it is without maintainers I'm closing this PR. If anyone new comes along they can ask for an exception if they feel they need it.

darkdragon-001 commented 3 months ago

Ok, but please don't EOL maintained software. It's essentially a large warning for users and causes too much confusion.

Marking a package as EOL gives visibility of the unmaintained status to the people who care about the app. These people are the most likely ones to step up and maintain the package going forward. So this sounds like a reasonable approach to me.

I've reverted the EOL PR for now, I'll ask if anyone from upstream is interested in maintaining this. If not we can EOL it.

Would be great if upstream was interested in maintaining it themselves. In the past, myself and others have asked several times but so far didn't find someone interested to continue maintaining it.

hfiguiere commented 3 months ago

Marking a package as EOL gives visibility of the unmaintained status to the people who care about the app. These people are the most likely ones to step up and maintain the package going forward. So this sounds like a reasonable approach to me.

It's as reasonable as a 5 year old throwing a tantrum.

If you don't like a party, you just leave. You don't torch the place.

darkdragon-001 commented 3 months ago

If you don't like a party, you just leave. You don't torch the place.

I started the party myself by adding the package in the first place and maintaining it tirelessly for years. I feel responsible for the users I have served so far.

The phrasing which I face here is exactly the reason why fewer people want to maintain packages. No gratitude for my hard work, only criticism.