> On Mar 24, 2016, at 23:25, Xidorn Quan <quanxunz...@gmail.com> wrote: > >> 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?
No. See bug 1186064 regarding the current state of VS2013. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
