After bug 853071 lands, the release mozconfig is going to be almost empty, because it sources everything from the beta one. We need to have the mozconfig comparison logic take that into account before comparing.

We need this bug to support bug 853071 in release automation. 23.0b1 will be the first release with that code.

Upon looking into this bug a bit further I realized that implementing it as described is going to be tough because we don't have a full gecko repository available when we do the comparison (we just download the mozconfigs individually). Rather than trying to replicate bash sourcing logic in Python, this approach lets lets the nightly, beta and release mozconfigs all inherit one thing. I think that factoring all of the things for opt builds into one file is generally a good thing, but I'm certainly biased at the moment! If this approach seems OK, I'll do a full patch for all platforms. I also noticed that we still have qt/rpm mozconfigs in the tree. Those builds have been dead for a long time.

Comment on attachment 757537 [details] [diff] [review] alternative solution Sounds good to me!

Comment on attachment 757537 [details] [diff] [review] alternative solution Forgot that gps is away. Ted, any chance you can give feedback on this this week? We need to resolve this bug before the next uplift.

Comment on attachment 757537 [details] [diff] [review] alternative solution Review of attachment 757537 [details] [diff] [review]: ----------------------------------------------------------------- Having the extra layer of indirection for the beta mozconfig kind of sucks, but it's not terrible and it does make things more straightforward otherwise. My only complaint is that "common-opt" is not the most descriptive name, but I also don't have a better suggestion. Maybe you could just put a descriptive comment at the top of it indicating that it's sourced by nightly/beta/release builds?

Here's the full patch w/ all platforms. I killed shark mozconfigs too. I used --no-renames because I thought it was a little easier to read this way, let me know if you want the other version. I also did some automated verification to make sure the new fully sourced mozconfigs matched the old fully sourced ones.

Same here, just without the --enable-profiling stuff.

Oh, and try runs w/ the new nightly configs are here: https://tbpl.mozilla.org/?tree=Try&rev=0074876b721d https://tbpl.mozilla.org/?tree=Try&rev=c99cb442c826

Comment on attachment 759144 [details] [diff] [review] full patch, for mozilla-central Landed on mozilla-central.

Comment on attachment 759145 [details] [diff] [review] full patch, for mozilla-aurora This is looking fine on central. A few options have changed order when looking at the output of client.mk, but that's to be expected. [Approval Request Comment] User impact if declined: Potential for mozconfig changes required for release to be missed in the 24 cycle. Testing completed (on m-c, etc.): Landed fine on m-c, local diffs of before/after changes to mozconfigs done. Risk to taking this patch (and alternatives if risky): Small potential for build config to change. Very unlikely given testing already completed. String or IDL/UUID changes made by this patch: None

Comment on attachment 759145 [details] [diff] [review] full patch, for mozilla-aurora Pushed to aurora.

This bug makes me happy.