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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to