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