Soft code freeze for Firefox 73 starts January 2

2020-01-01 Thread Liz Henry (:lizzard)
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

2019-08-21 Thread Liz Henry (:lizzard)
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

2019-08-21 Thread Liz Henry (:lizzard)
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

2019-01-14 Thread Liz Henry (:lizzard)
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

2018-06-14 Thread Liz Henry (:lizzard)
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

2017-07-13 Thread Liz Henry (:lizzard)
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

2017-06-16 Thread Liz Henry (:lizzard)
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

2017-06-01 Thread Liz Henry (:lizzard)
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)

2017-04-18 Thread Liz Henry (:lizzard)
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

2017-04-06 Thread Liz Henry (:lizzard)
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

2016-09-08 Thread Liz Henry (:lizzard)
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

2016-06-01 Thread Liz Henry (:lizzard)
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

2016-04-07 Thread Liz Henry (:lizzard)
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

2015-06-29 Thread Liz Henry (:lizzard)
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