On Fri, Mar 25, 2016 at 12:44 AM, Gregory Szorc <g...@mozilla.com> wrote:

> On Wed, Mar 23, 2016 at 7:03 PM, Gregory Szorc <g...@mozilla.com> wrote:
>
> > On Wed, Mar 16, 2016 at 11:49 PM, Gregory Szorc <g...@mozilla.com> wrote:
> >
> >>
> >> On Thu, Mar 10, 2016 at 8:14 AM, Gregory Szorc <g...@mozilla.com> wrote:
> >>
> >>> Visual Studio 2015 has been out for a while. Many people have put in
> >>> work to make Firefox build on it. The time has come to officially
> >>> transition release builds from Visual Studio 2013 to Visual Studio
> 2015.
> >>>
> >>> This email serves as an intent to switch automation to Visual Studio
> >>> 2015 Update 1 (latest stable release) as soon as possible, hopefully in
> >>> the next week or two.
> >>>
> >>> A big driver for the switch is that builds with VS2015 are faster. PGO
> >>> builds in automation are 1+ hour faster than with VS2013 (see data in
> bug
> >>> 1250797)! (Windows PGO builds are a long pole in the release process
> and
> >>> therefore prevent us from releasing faster - this is highly relevant
> during
> >>> chemspills.)
> >>>
> >>> A host of new C++ features should be available after the switch.
> >>> Although, we may have to drop support for VS2013 before those can be
> fully
> >>> realized. I defer to others to determine when VS2013 will be dropped.
> >>>
> >>> I feel like 95% of the transition work is completed. However, the
> >>> following Try pushes appear to have some new failures:
> >>>
> >>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=d67e4a1f3735
> >>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c2a7b4e81d0
> >>> (PGO)
> >>>
> >>> (Ignore SpiderMonkey failures - they are due to how the toolchain is
> >>> being hackily installed in those Try pushes.)
> >>>
> >>> I could use your help triaging test failures and fixing fallout so we
> >>> can complete the transition to VS2015.
> >>>
> >>> I'm very much a fan of perfect is the enemy of done and I feel
> temporary
> >>> workarounds (like e.g. disabling tests if there appears to be a minor
> >>> regression) may be warranted so we can give VS2015 extra time to bake
> on
> >>> Nightly. Otherwise, this may slip ~6 weeks until the next release. I
> feel
> >>> like we're too close to being able to transition to VS2015 to wait ~6
> more
> >>> weeks.
> >>>
> >>> Bug 1186060 is our master tracking bug for the VS2015 switch.
> >>>
> >>> Thank you for everyone that has contributed to VS2015 fixes so far.
> >>> Thank you in advance for helping complete the transition.
> >>>
> >>
> >> (+1 week progress report)
> >>
> >> All Windows builds are now working with VS2015u1 running from tooltool
> >> (read: we have a zip file containing all the toolchain files so we don't
> >> need changes to build machines to roll out new Visual Studio / SDK
> versions
> >> going forward). This includes PGO and SpiderMonkey builds.
> >>
> >> Talos numbers are at
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1254767#c9 and
> >> investigation into changes is ongoing. There are some concerning
> >> regressions - particularly around e10s - that have yet to be explained.
> >>
> >> Bug 1124033 has turned into a rabbit hole *and I could use help*. When
> >> VS2015 support was first added to the build system, new-to-VS2015
> compiler
> >> warnings were blanket disabled. Bug 1124033 is about undoing that and
> >> enabling those warnings. There are 20+ open bugs tracking fixing
> compiler
> >> warnings. I've submitted patches to wallpaper over them by disabling
> >> warnings in specific files or directories. But this is not optimal: we
> >> should just fix the underlying warnings and leave the warning detection
> >> enabled. Unfortunately, my C++ knowledge is about 10 years out of date,
> >> very rusty, and I know very little about the C++ conventions used in
> >> mozilla-central. This is where I could use help. *If you see a bug
> chained
> >> up to bug 1124033 related to VS2015 compiler warnings, I'd appreciate
> help
> >> with patches to C++ to fix the warnings.*
> >>
> >> If you'd like to submit Try pushes using VS2015,
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1124033#c21 contains
> >> instructions.
> >>
> >> I'm still optimistic we'll be able to perform the switch (or at least
> >> attempt the switch) this release cycle.
> >>
> >
> > (+2 week progress report)
> >
> > Thanks to a lot of help from a lot of people, the compiler warnings
> > strategy for VS2015 is now much better. Before, we had globally disabled
> > all new-to-VS2015 compiler warnings. With bug 1124033 landing on inbound
> a
> > few minutes ago, only C5026 and C5027 are now globally disabled. Many
> > compiler warnings were fixed. Others were worked around by disabling
> > specific warnings in moz.build files. The intent is to remove these
> > workarounds and bugs have been filed to track their removal.
> >
> > At this point, the only blockers to VS2015 landing are bug 1255656 and
> bug
> > 1257722. And I'm pretty confident those will get sorted out soon.
> >
> > So if everything goes according to plan, VS2015 will land tomorrow. You
> > may want to prepare by installing VS2015 on your machines.
> >
>
> Inbound is now building with VS2015!
>
> Thank you to everyone who helped with the transition over the past ~1 year.
> I only got involved at the end of this effort. IMO the people who came
> before and worked through the long tail of compiler warnings and random
> issues related to compiler upgrades deserve the bulk of the recognition for
> getting us where we are today. Thank you.
>

Hooray \o/

Does that mean we also officially dropped the support of VS2013? If we stop
building with VS2013 on the infra, it could be broken soon.

- Xidorn
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to