Hi, As I did those updates.. On Friday, 2022-09-02 17:49:57 +0000, Mattia Verga via devel wrote: > Here we go again: thunderbird 102 update was submitted to F36. Actually we already had 102.2.0 a week before on 2022-08-23 with https://bodhi.fedoraproject.org/updates/FEDORA-2022-ddee3eb27c for f35 https://bodhi.fedoraproject.org/updates/FEDORA-2022-33dd0f2f3e for f36 after Jan did the rebase to 102.1.0 that was not pushed. We maybe could had gone with 91.13.0 instead of 102.2.0, backing out the rebase for one update, but that was the last 91.x release and newer security fixes will not be released for it, specifically that high-impact CVE-2022-3033 information leak fixed with 102.2.1 is not adressed there. > This new version was known to bring incompatible changes to several > addons, I wasn't aware of that, I'm "only" doing the security updates, and the update to 102.2.0 didn't bring any such up. The releasenotes don't indicate such either: https://www.thunderbird.net/en-US/thunderbird/102.0/releasenotes/ https://www.thunderbird.net/en-US/thunderbird/102.1.0/releasenotes/ https://www.thunderbird.net/en-US/thunderbird/102.2.0/releasenotes/ Furthermore the 102.2.0 release isn't marked as "not as an upgrade from Thunderbird version 91 or earlier" anymore, which 102.0 and 102.1.0 were. > yet it has been submitted to a stable Fedora release with > autopush enable and just a karma threshold of 2. It took less than 5 > hours from the time the update was submitted to the time the update was > pushed to stable. I chose karma +2 because the past has shown that it rarely gets more votes in f36 and in f35 even less and thought that security updates shouldn't linger around more than necessary. > Package maintainers should put more attention when pushing critical > updates like this and avoid that the update being immediately pushed to > stable. Now, holding off only the 102.2.1 push with https://bodhi.fedoraproject.org/updates/FEDORA-2022-4fcde117f2 for f35 doesn't make sense with 102.2.0 already being in. If for Thunderbird a rebase really would need a FESCo exception then that seems to be a new handling for Thunderbird as also in the past there were rebases from for example 78.11.0 to 91.1.0 in stable f33/f34 (I wasn't involved with) when 78.x was discontinued. But this then seems to be a more general problem of how we want to support a switch an application from one ESR/LTS release if it is EOL to the next. Eike -- GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
