I see no reaction here after 6 months, and after all the discussions we've had with Mint folks in the years prior.
At this point, I have no choice but to ask again: @clefebvre please completely stop packaging GNOME Calendar in Linux Mint, or rename it all (including package names, executables' names, etc.) so that it reflects the fact that it has nothing to do with the code that the GNOME Calendar developers test, ship and actively support.

http://packages.linuxmint.com/search.php?release=any&section=any&keyword=gnome-calendar shows that your repositories still offer GNOME Calendar 3.36 to 46, and even that version 46 is 4 versions (i.e. 2 years) behind.

I am still regularly on the receiving end of Linux Mint users complaining on our bug tracker (and social media) about things that have been fixed aeons ago, while they are still running the 4.5 years-old version 41 provided by Mint (to give you an idea of the magnitude of the problem: we have fixed over 450 bugs since that version, and we solve about 50 more issues each release on average). I also strongly object to your downstream modifications of our app against our will, increasing the variability and support burden on our side. Your approach is not sustainable for anybody, and Mint users end up having to bypass your packaging anyway if they want a functional app. It would be much easier if you would just drop the package entirely and let the users get it from us, but otherwise it must not be called "GNOME" calendar anywhere because what you are shipping is not the experience intended for our users.

Hi Jeff,

Many of the releases on that link are outdated and no longer supported. Our current releases provide 46 and 48 which match what's provided by Ubuntu LTS and Debian Stable.

Which modifications do you not like?

None of us have the time to analyze the source code and/or try out your fork, so we can't pinpoint anything besides "everything".

Both 46 and 48 are massively behind. Undoing these modifications won't fix the underlying problem whatsoever. What will solve it is either dropping the package altogether or rebranding the fork and replacing all the links pointing to GNOME with yours.

Hi Hari,

I reviewed the changes. None of them are problematic.

As i said, 46 and 48 are used by millions of people right now in Ubuntu LTS and Debian Stable. Are you going to request Debian and Ubuntu stop shipping GNOME apps?

I reviewed the changes. None of them are problematic.

I repeat: Undoing these modifications won't fix the underlying problem whatsoever. What will solve it is either dropping the package altogether or rebranding the fork and replacing all the links pointing to GNOME with yours.

Instead of fixating on these "changes", the fact of the matter is that the broken versions of GNOME Calendar you're distributing, which cover our brand, mislead your users into opening bug reports on our issue tracker.

As i said, 46 and 48 are used by millions of people right now in Ubuntu LTS and Debian Stable. Are you going to request Debian and Ubuntu stop shipping GNOME apps?

This is about Linux Mint's package, not Debian Stable or Ubuntu LTS. Dozens of people who report these issues to us are Linux Mint users who are using the package provided by Linux Mint. We don't care about which package sucks; we care about whose unsupported version bothers and distracts us on a regular basis — in which case, it's the package provided by Linux Mint. If Debian Stable and Ubuntu LTS's packaging of GNOME Calendar bother us regularly, then yes, we will request them to stop shipping GNOME Calendar (not "GNOME apps") or rebrand it. As it stands, they are not bothering us.

The only difference between GNOME Calendar in Ubuntu LTS and GNOME Calendar in Mint 22.3 is that bug fix you don't care about.

If we were to stop packaging GNOME Calendar, Mint users would end up with the exact same version 46 as now. You understand that? It wouldn't magically upgrade their version of GNOME Calendar to 50+.

I'll explain a little bit more because it's probably not obvious if you never used Mint.

Mint 22.x is built on top of Ubuntu 24.04 LTS. Packages come from both repositories. If there's no gnome-calendar in Mint 22.x repositories, Mint 22.x users get it from the Ubuntu 24.04 repositories. The version in both repositories is 46. Removing gnome-calendar from our repositories would basically make our users switch to Ubuntu's version, which is 46 as well.

The only difference for them would be the loss of that bug fix I mentioned.

Same goes for LMDE and Debian Stable, same principle, same bug fix, with version 48.

The only way to make it so Mint doesn't have a frozen version of gnome-calendar would be to remove it from Debian. It would then disappear from future versions of Ubuntu and Mint which are based on it. If you got it removed from there we'd obviously oblige with your request not to re-add it and wouldn't do so.

I hope that helps.

If we were to stop packaging GNOME Calendar, Mint users would end up with the exact same version 46 as now. You understand that? It wouldn't magically upgrade their version of GNOME Calendar to 50+.

I never said or implied as such. Sure, current users will retain that install, but those who want a working calendar app won't easily be misled by it in the future.

Mint 22.x is built on top of Ubuntu 24.04 LTS. Packages come from both repositories. If there's no gnome-calendar in Mint 22.x repositories, Mint 22.x users get it from the Ubuntu 24.04 repositories. The version in both repositories is 46. Removing gnome-calendar from our repositories would basically make our users switch to Ubuntu's version, which is 46 as well.

The only way to make it so Mint doesn't have a frozen version of gnome-calendar would be to remove it from Debian. It would then disappear from future versions of Ubuntu and Mint which are based on it. If you got it removed from there we'd obviously oblige with your request not to re-add it and wouldn't do so.

If dropping it will have it fall back to Ubuntu's or Debian's repos, then you can add it/them to the denylist alongside. There wouldn't need to be an additional process to request Debian to drop or rebrand a non-problematic package. Besides, if we're asking you to stop shipping unsupported versions of Calendar with our branding to your users, then it is your responsibility to take care of that, either by asking Debian to do it for you, or artificially denylisting the gnome-calendar package. We shouldn't be the ones doing it for you.

We've no say in whether or not GNOME Calendar goes in Debian. If it's in Debian it's in all Debian derivatives, that won't change.

We can patch the about dialog to remove the links. That will help short-term but to tackle the issue long-term you need to do the same upstream in your current version, or implement some kind of way for the link not to disappear once the version becomes unsupported. Have you thought of a technical solution to implement this?

Otherwise we'll have to constantly patch that going forward. That patch should be done in Debian also, because there's absolutely no reason why this should be a problem in Mint and not in Ubuntu and Debian as well.

We can patch the about dialog to remove the links. That will help short-term but to tackle the issue long-term you need to do the same upstream in your current version, or implement some kind of way for the link not to disappear once the version becomes unsupported. Have you thought of a technical solution to implement this?

How do you suggest upstream achieves this without either phoning home or baking in an expiry date?

I understand that you don't want to set up a CI/CD pipeline for every GNOME application to patch in your own support links, that sounds like a lot of work.

Either way, I do agree with you that this work should be performed in Debian so it can more easily move downstream, but the vast majority of reports come from inexperienced Mint users who blindly follow the "About" menu, versus Debian users who tend to be power users and know that the "About" menu is lying and that issues should be reported to Debian.

If I was to do it myself, I would inject the version in the URL and automate how I handle "old" versions server-side. That assumes a custom server infrastructure though so it's not ideal. If this is a GNOME-wide concern about frozen distributions an easier solution would be a downstream patch on libadwaita. Even if, at release time, we were to ship the latest versions, it's only a matter of time before our GNOME apps get considered "old" upstream. Most people are happy to be told something is or will be fixed in a newer version, even if they don't have access to it just yet. If that feedback is unwelcome then the best thing is for these links not to appear. Carrying that patch on libadwaita is easy and can be done permanently, ideally by Debian to tackle the issue in all derivatives, or by Mint directly.

To address the social media and matrix aspects Hari talked about, I've no easy solution. The only way to prevent users from using older releases would be through licensing which prevents distributions to ship it, or to implement your own in-app update mechanism (similar to Discord for instance).

We've no say in whether or not GNOME Calendar goes in Debian. If it's in Debian it's in all Debian derivatives, that won't change.

[...]

Otherwise we'll have to constantly patch that going forward. That patch should be done in Debian also, because there's absolutely no reason why this should be a problem in Mint and not in Ubuntu and Debian as well.

And we have no interest in these intricate details. We want you to rebrand and remove these links in your distribution, that's all. It is your responsibility to figure out how to go about doing it, not ours. Whether you want to constantly patch the app is entirely up to you to decide. I suggested you to fork, and never mentioned patching the app.

So please, stop with the whataboutism. It doesn't matter to us if Debian's and Linux Mint's package share the same technical problems; we only care about which packages drain our energy, in this case being Linux Mint's. And honestly, shame on you for pushing this onto Debian.

We can patch the about dialog to remove the links.

No, that's not enough. We want you to rebrand it and remove these links.

Have you thought of a technical solution to implement this?

Yes. My conclusion is simple: there is no technical solution to a societal problem. Your unwillingness to take accountability and pushing these responsibilities onto Debian is proof of that. In any case, if an upstream needs to keep redirecting users to a downstream, then this downstream has utterly failed in its mission, and should reevaluate its flawed method of handling this.

And we have no interest in these intricate details.

OK. If you don't care, then neither do we.

Why? It's literally your responsibility to know the ins and outs of Debian, and collaborate with them to ensure a healthy relationship if you want to keep relying on them. At this point, you're not only abusing your power as a downstream by avoiding accountability and misleading your own users into opening issues in the wrong place just because you can, you're also abusing Debian's generosity by making them do your dirty work.

Why? Maybe just re-read everything I said? I already explained everything, calmly and as an adult.

And what do I do with this information? Like I said it's not our responsibility as an upstream to send these patches to Debian - expecting us to do so is absurd.

Let me be a little bit insulting as well, since you're so aggressive. I'm not expecting you to be reasonable. You placed a link in your app you don't want people to click on. It's not rocket science. The more obnoxious you are in the way you talk to us the less we'll be willing to help you.

Isn't it standard practice to have an issue template that makes the reporter confirm the version of the package? Be it a checkbox confirming at least x version is used or a field to specify the version (which you could automate checking and close the issue kf it's too old).

Indeed.

Not every (formal or informal) issue report resides in an issue tracker; this often happens in social media, chat (Matrix), etc., which don't have a concept of an issue template

Ah so it's not just the link. You just don't want people to run older versions at all. Then the solution is simple, you're using the wrong license. See, the license you're using is free software, it gives anyone the right to use and distribute your software. What you want instead is a restrictive license which forbids redistribution and controls delivery to ensure people only use your latest version, it could be restricted to snap, flathub and/or GNOME OS.

Obviously, nobody wants to interact with child molesters. Please let's stay on topic though, this is about a request for a patch. It has nothing to do with GNOME's code of conduct or anyone's criminal record.

Upstream wants tight control over the distribution of its software. This probably requires GNOME Calendar to move away from free licenses. Closing since this an upstream consideration.