Soft code freeze for Firefox 73 starts January 2
Hello everyone, We're nearing the end of the Nightly 73 cycle as well as the end of the year and the decade! In order to avoid invalidating the testing we get out of late Nightly and to ensure that we can roll out Beta 73 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from January 2 until after the version bump to 74 on January 6. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affect the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in the Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Liz & the release management team -- ---- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soft code freeze for Firefox 70, Aug 26
Correction, avoid risky changes from Aug 26th to Sept 2. Thanks to kwierso for pointing out my typo. - Liz On Wed, Aug 21, 2019 at 10:41 AM Liz Henry (:lizzard) wrote: > Hi there, > > On August 26th, we will be merging Firefox 70 from mozilla-central to beta > for the first time. In order to avoid invalidating the testing we get > out of late Nightly and the early Developer Edition builds and to ensure > that we can roll out Beta 70 to a wider audience with confidence, we'd > like to ask that any risky changes be avoided from July 1st until after > the version bump to 71 on Sept 2. Please also be mindful of any > landings late this week or over the weekend as there will be very little > buffer between the first merge and shipping the 70.0b1 builds. > > Some reminders for the soft code freeze period: > > Do: > - Be ready to back out patches that cause crash spikes, new crashes, > severe regressions > - Monitor new regressions and escalate merge blockers > - Support release management by prioritizing fixing of merge blockers > > Do Not: > - Land a risky patch or a large patch > - Land new features (that affects the current Nightly version) — be > mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can > lead to unexpected CI results > - Flip prefs that enable new Features that were untested in Nightly cycle > - Plan to kick off new experiments that might impact a feature's merge > readiness > > Please let us know if you have any questions/concerns. > > Thanks, > > Release Management Team > > > -- > > Liz Henry (:lizzard) > Firefox Release Manager > lhe...@mozilla.com > -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 70, Aug 26
Hi there, On August 26th, we will be merging Firefox 70 from mozilla-central to beta for the first time. In order to avoid invalidating the testing we get out of late Nightly and the early Developer Edition builds and to ensure that we can roll out Beta 70 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from July 1st until after the version bump to 71 on Sept 2. Please also be mindful of any landings late this week or over the weekend as there will be very little buffer between the first merge and shipping the 70.0b1 builds. Some reminders for the soft code freeze period: Do: - Be ready to back out patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affects the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Release Management Team -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soft code freeze for Firefox 66 starts January 21
Hi all, On January 21, we will be merging Firefox 66 from mozilla-central to beta for the first time. In order to avoid invalidating the testing we get out of late Nightly and the early Developer Edition builds and to ensure that we can roll out Beta 66 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from January 21 until after the version bump to 67 on January 28. Please also be mindful of any landings late this week or over the weekend as there will be very little buffer between the first merge and shipping the 66.0b1 builds. Some reminders for the soft code freeze period: Do: - Be ready to backout patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affects the current Nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Release Management Team -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Reminder: soft code freeze for Firefox 62 starts today, June 14
Hi y'all, On June 18th, we will be merging Firefox 62 from mozilla-central to beta for the first time. In order to avoid invalidating the testing we get out of late nightly and the early Developer Edition builds and to ensure that we can roll out Beta 62 to a wider audience with confidence, we'd like to ask that any risky changes be avoided from June 14th until after the version bump to 63 on June 25th. Some reminders for during the soft code freeze: Do: - Be ready to backout patches that cause crash spikes, new crashes, severe regressions - Monitor new regressions and escalate merge blockers - Support release management by prioritizing fixing of merge blockers Do Not: - Land a risky patch or a large patch - Land new features (that affects the current nightly version) — be mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to unexpected CI results - Flip prefs that enable new Features that were untested in Nightly cycle - Plan to kick off new experiments that might impact a feature's merge readiness Please let us know if you have any questions/concerns. Thanks, Release Management Team -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Merge Day changes coming up soon
Hi there, Release management and release engineering have changed the dates for the next release cycle's merge day. Firefox 56 will move to mozilla-beta, and Firefox 57 will become Nightly, on August 2 (rather than August 7). You should still be able to check in patches to mozilla-central normally. For anything that you need to land for 56 beta 1, between August 2 and 7, please request uplift to beta. We'll still be doing the beta 1 build on Monday, August 7 for release on Tuesday, August 8. This should give much more time for sheriffs and releng to fix tests and resolve merge related issues. It will limit last minute churn for the last 5 days before the beta release, while still keeping m-i and m-c open. I think it will give us an improved chance of shipping beta 1 on schedule. We're also planning on repeating this pattern for the 57 move to beta in September, so 57 will move to mozilla-beta, and 58 to m-c, to become Nightly, on Sept. 20th instead of Sept. 25. Thanks to Aki for this plan, and to the l10n team, release duty folks, relman, release-drivers, and the comms team for feedback on how to make it work. If you have questions or other feedback, please let me know. Best, Liz -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: BaseThreadInitThunk potential collateral benefits
I'm so happy for this hammer to slam down. Goodbye, at least a good bit of horrible DLL injections and crashes, and horrible BaseThreadInitThunk. Thanks for the explanation. The suggestions for next actions sound good too. - Liz On Mon, Jun 5, 2017 at 2:36 PM, David Durst <ddu...@mozilla.com> wrote: > Hi. > > I wanted to call attention to https://bugzilla.mozilla.org/ > show_bug.cgi?id=1322554 (Startup crashes in BaseThreadInitThunk since > 2016-12-03) -- a startup crash resulting from DLL injection early in the > process -- which was resolved fixed for 32bit Windows on 5/24. > > This particular fix[0] has the potential side effect of solving other bugs > as well, ones that may have very different signatures that deal with > remotely-injected code[1]. > > Just a caution that it's not going to impact all injection issues. We know > that there is an as-yet-unidentified increase and decrease in this crash > prior to patch landing[2]. Carl Corcoran, who landed this, will be looking > at that time period as well to attempt to find contributing causes (any > help diagnosing is probably welcome, though I defer to ccorcoran). > > Also, just a shout out that this was Carl's first patch. > > Thanks! > > > [0] The proposed/chosen solution is roughly here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1322554#c69 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322554#c168 > [2] https://crash-stats.mozilla.com/signature/?product= > Firefox_channel=release=BaseThreadInitThunk=%3E% > 3D2016-12-05T14%3A42%3A31.000Z=%3C2017-06-05T14%3A42%3A31.000Z#graphs > > -- > David Durst [:ddurst] > > ___ > Stability mailing list > stabil...@mozilla.org > https://mail.mozilla.org/listinfo/stability > > -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: SourceMap header
Is there any objection to landing the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1346936 and shipping it in 55 as it stands now? I read this thread and can see there is a lot that could and maybe should be done with writing a spec and engaging with standards orgs. But, does that block us shipping? Do we have enough test coverage and so on? And, any feedback here from the JS team? Best, Liz On Fri, May 26, 2017 at 11:53 AM, Domenic Denicola <d...@domenic.me> wrote: > (Re-sending as I was informed that "posting by email is not allowed"; > apologies to those who get this email twice.) > > From: mozilla.dev.platf...@googlegroups.com [mailto:mozilla.dev.platform@ > googlegroups.com] On Behalf Of L. David Baron > > > > On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote: > >> How would I go about starting this? > >> I have never done anything with web standards before. > > > > Probably something like: > > > > (1) ask the current maintainers of the spec if they're ok with you > doing this > > This speaks to the larger issue here, which is finding someone who is > willing to devote ongoing effort to maintaining the spec. It's a serious > long-term commitment, not just something to check off the box before > shipping a new feature. My understanding is there are current maintainers > who are happy with their workflow using a Google doc. If you want to move > to a new technology, you need to get them to come along and help with the > conversion process, and you need to stick around as part of the team > committed to maintaining the spec long-term, driving consensus on new > features. > > https://whatwg.org/working-mode may give you somewhat of an idea of how > the ongoing process of maintaining a spec works. It is for a different > standards organization than the one dbaron suggests, but the general > framework remains. > > (BTW, if the spec ends up successful in the WICG, we can talk about > migrating it from incubation in the WICG to a full-fleged WHATWG > specification, as was suggested by some people up-thread. But it would be > good to see ongoing positive signs of engagement first with the proposed > new spec.) > _______________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: window.find dialog feature broken in Firefox 53 (a.k.a., Late Intent to Unship: window.find's dialog support)
Just a quick note that I'm not going to consider this a release blocker for 53. We don't think this is commonly used API, and it is non-standard. We can think about it as a fix to include for a potential 53 dot release a couple of weeks from now. Best, Liz On Tue, Apr 18, 2017 at 11:15 AM, Mike Conley <mcon...@mozilla.com> wrote: > Hello release-drivers (with dev-platform cc'd), > > TL;DR: The non-standard window.find feature[1] has, historically, been > able to open up a dialog for the user to enter more strings to find on > the page[2]. It turns out that the dialog portion of that API has been > broken for all users with e10s enabled since e10s started shipping. > Starting with Firefox 53, we're breaking the dialog portion of the API > for non-e10s users as well. In bug 1348409[3], I have a patch cooking > that will disable the dialog functionality in a more deliberate way. > > Longer version: > > It appears that either bug 1182569 or bug 1232432 (or both) have broken > the part of the non-standard window.find API that can show a dialog to > the user, and that this breakage is about to go out in Firefox 53. > > It also turns out that dialog feature has _never_ been supported with > e10s enabled. > > The fact that we're only finding this out now says something about our > test coverage for this feature. > > If it's any solace though, our documentation[1] spells it out pretty > clearly that this is a non-standard API, and that support varies widely > across browsers. My own testing indicates that the dialog is not shown > for IE 11, Edge, Safari 10.1, or Chrome 57 (on OS X). I have no idea if > they ever supported it in the past. IE and Edge don't seem to have > window.find support in general. > > I have a patch cooking in bug 1348409 that disables the attempt at > opening the dialog. I'll go one of two ways - either returning false > from window.find as soon as we enter the case where we would have opened > a dialog, or just ignoring the dialog request entirely (this is what > Blink / WebKit seem to do, and what I'm leaning towards). > > Anyhow, just a heads up. I hope I didn't ruin anybody's day. > > -Mike > > [1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/find > [2]: http://www.javascripter.net/faq/find_dia.htm has a demo you can try > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1348409 > _______ > release-drivers mailing list > release-driv...@mozilla.org > https://mail.mozilla.org/listinfo/release-drivers > -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Moving the 53 Merge and Release dates to accomodate Easter holiday
Hi release-drivers and others, Because Monday April 17th is part of the Easter holiday in many countries, we decided to move the Firefox 53 merge and release dates by one day. Merge day will now be Tuesday, April 18, and we plan to release Firefox 53 on Wednesday, April 19. The dates are changed in the public release calendars. Best, Liz -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Delay for 49 release to Sept. 20th
Hello Platform and Firefox teams, Because of two blocking issues and the need for a bit more time to evaluate the results of their fixes/backouts, we need to push back the upcoming merge and release dates. We will plan for merge day to be Monday Sept. 19th, with release planned for Tuesday Sept. 20th. 50 will continue as aurora, and 51 as nightly for next week. The 50 beta cycle was planned to be 8 weeks. We can afford to lose a week there and still aim to ship 50 as scheduled. We will need to build, test, and release a 49 RC3 (release candidate). I may aim for an RC3 build tomorrow, with release next Monday, Sept. 12. We also may wait to do the RC3 build on Monday for release the next day. Then we will have several days to evaluate telemetry data and other criteria, and have confidence we are shipping the best option to Firefox users. You can see the current list of blocking and other issues in play, here: https://public.etherpad-mozilla.org/p/49-blockers Please let me know if you have feedback or any questions, by email or on IRC on #release-drivers. Best, Liz -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for VS2013
Hi Greg and others, I was just about to raise the issue of performance regression from this change. If we are aiming this at the 49 release, I would like for us to improve the situation described in bug 1259923, a 15% performance regression across all Talos tests covering Windows platforms, which Joel brought to my attention yesterday. I don't think we can accept that if it means a large noticeable slowdown in performance for Windows users in the release population. (Even though we really, really want to improve the toolchain and build time for developers and our own infrastructure.) Can we put some engineering resources into investigating the test results and mitigating the perf regression? 15% worse across all Windows tests should probably block the release. We don't have hard and fast criteria for what would be an acceptable perf hit. I think the platform (and probably product team) should discuss that. Thanks, Liz On Tue, May 31, 2016 at 4:22 PM, Gregory Szorc <g...@mozilla.com> wrote: > Heads up: we'll soon be dropping support for building mozilla-central with > VS2013. Bug 1186064 tracks and the patch has already received r+. > > I'm going to wait a few days before landing because this could be > disruptive and I want to at least give a heads up before I create a fire. > Please install VS2015 in the next 48 hours to avoid a surprise the next > time you pull. > > (We've previously recommended everyone install VS2015, so this > announcement should come as no surprise.) > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
[desktop][mobile] Firefox 46 release moved up a week to April 26
Hello dev-platform and firefox-dev, We are delaying the release of Firefox 46 for a week. Short version: For the Firefox 46 cycle, merge day is now April 25. Release is April 26. The 47 release schedule hasn't changed; release still planned for June 7. Here are some details: During the 46 beta cycle various issues delayed or prevented several beta releases. In order to get better crash data and to be able to respond to crashes reported this week in beta 7, 8, and 9, we are going to delay shipping Firefox 46 by one week. We plan to ship beta 9 this Thursday, and beta 10 and 11 next week. This also will allow for more l10n changes to land. Firefox 46 and the corresponding ESR versions are now planned for release on April 26. The beta cycle for Firefox 47 was planned to be seven weeks, releasing on June 7.We will shorten that cycle to six weeks. The release date for Firefox 47 will still be June 7th. Therefore, we don't need to adjust the calendar for the rest of the year. We're just "stealing" a week from beta 47 and using it to extend beta 46. The merge dates will also move a week, which means we have an extra week for Nightly 48 and Aurora 47 before the merge on April 25. You can see the release schedule from our public calendars linked from here: https://wiki.mozilla.org/Release_Management One calendar has just the merge and release dates. The other calendar has more details and is mostly used by release managers and release engineers. Hope this is clear. Please ask if you have any questions - email is fine, or on irc you can find me as lizzard on #relman or #release-drivers. Best, Liz -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FYI: Change in crash signature naming in crash-stats
There has been a change in how Socorro records crash signatures. All signature pieces between and are now collapsed into T. That means that some crashes look like they stopped on June 12, when they really have not. Please be on the lookout for this as you interpret crash-stats. Here's the Socorro bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1163831 Example of this resulting in crash looking oddly fixed : https://bugzilla.mozilla.org/show_bug.cgi?id=1167557 This should be affecting tools built to identify significant crashes. It also means that people looking at particular crash signatures to verify if a crash sig has disappeared (often the best verification we can manage for a crash bug) or is getting worse. Best, Liz -- Liz Henry (:lizzard) lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
