Hi all, Interesting, I had no knowledge of those specific needs for RedHat. I’ll document that in the release management page so that it doesn’t happen in the future.
Bob, would it be useful if I released a 3.68.1 version reverting the NSPR requirements to 4.30 early next week ? Kai, if the solution above could be useful for Bob, my understanding is that it would be ok for NSS 3.68.1 and the future dot releases for ESR to remain on NSPR 4.30 since we don’t use the changes within NSS. Firefox could keep using 4.32. Is that correct? About the release notes of 3.68, looks like I just forgot, sorry about that. B. > On Aug 20, 2021, at 7:36 PM, Robert Relyea <rrel...@redhat.com> wrote: > > On 8/20/21 1:44 AM, Kai Engert wrote: >> Hello Bob, >> >> you didn't say which ESR version your report is about. Is it about the old >> ESR 78, or the new ESR 91? >> >> It seems old ESR 78 didn't have any changes recently. >> >> The most recent changes to new ESR 91 were: >> >> - use NSS 3.68 on 2021-07-13 >> >> https://hg.mozilla.org/releases/mozilla-esr91/log/tip/security/nss/TAG-INFO >> >> - use of NSPR 4.32 on 2021-07-13 >> https://hg.mozilla.org/releases/mozilla-esr91/log/tip/nsprpub/TAG-INFO >> >> I don't see any changes to NSPR/NSS in ESR 91 after it was released. > > I was 91. There wasn't an announcement on this list. I picked up 3.67 on June > 17, and completed the resulting builds on July 6. This change was made 1 week > after I was developement complete for the NSS portion of our Rebase. QA for > all our platforms are finishing this week (completed last week for RHEL > 9/RHEL 8). Changing base requirements for Firefox ESR this late means we can > only fail to meet any ESR schedules. As you know it take time to pick up > rebases, as well as meet all our internal deadlines. July 13 is way too late > for us to handle this kind of change to ESR. > > There are a lot of more reasons why it's extremely expensive for us to move > to NSS 3.68 on RHEL. What I need now is permission to ship our ESR with NSS > 3.67 (frankly I'm hosed if I don't get that). > > NSPR 4.32 may be less of an issue, but I'll need to know this week and many > decisions makers or on PTO. > >> >> The above changes were done prior to the ESR 91 beta date. >> >> Can you please clarify which of the above changes was problematic for you, >> and why? > > Moving ESR 91 to NSS 3.68 is highly problematic for us. In the future I'd > like to be in any of those discussions, particularly. ESR is a big deal and > big cost, we can't take last minute major revision bumps, particularly in NSS. > >> >> Furthermore, you are responding to an email about the NSS 3.69 release. ESR >> 91 doesn't use that, it's on NSS 3.68. > > yes, it was just a convenience. This has nothing to do with NSS 3.69, other > than the fact we never actually announced NSS 3.68 on this list (which makes > it even more problematic that we make it a requirement for ESR 91. > > > bob > >> >> https://kuix.de/mozilla/versions/ >> >> Kai >> >> >> >> >>> On 18.08.21 19:29, Robert Relyea wrote: >>> On 8/8/21 10:12 PM, Martin Thomson wrote: >>>> Network Security Services (NSS) 3.69 was released on 5 August 2021. >>>> >>>> The HG tag is NSS_3_69_RTM. NSS 3.69 requires NSPR 4.32 or newer. >>> >>> >>> Hey, was there a bump in the version requirements on NSS for ESR? This >>> is a serious problem for us. It takes us a month or so go get new >>> versions of NSS through our release process, so we need that runway >>> before we can pick up a new version of NSS. Dumping new requirements of >>> ESR makes it impossible for us to really plan that landing, as well as >>> makes it impossible to meet our new ESR release requirements before the >>> old ESR runs out. >>> >>> Do you know what requirements forced the bump. Can we get dispensation >>> to release with the older version of NSS. Also I'm not seeing a release >>> announcement for NSS 3.68, so there's no record of what the changes were. >>> >>> Please, in the future, do not pick up new version of NSS into ESR once >>> the schedule is made. It's better for us to pick up individual fixes >>> than rebase to a new version, and if you need to, please give us lots of >>> warning. >>> >>> Thanks, >>> >>> >>> bob >>> >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "dev-tech-crypto@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-tech-crypto+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/3ba8b72c-2520-5845-63ab-4c3c7d27b85a%40redhat.com. -- You received this message because you are subscribed to the Google Groups "dev-tech-crypto@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-crypto+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/91BAF476-9A2F-4536-BC5F-72340E44554F%40mozilla.com.
