As part of the Dawn project, we would like Aurora users to be migrated from Aurora channel to Beta channel post-merge of April 18th. Release train versions: Nightly - 55, Aurora - 54, Beta - 53 Post-merge (April 18th) Release trains version: Nightly - 55, Beta - 54.

Catlee and I talked about this and came up with a plan: * Freeze Aurora nightlies when 54 uplifts to Beta * Make in-tree changes that would make nightlies contain: ** An update-settings.ini that accepts beta+release MAR_CHANNEL_IDs ** An updater.exe that accepts beta/release mar certificates * Trigger new nightlies manually * Set-up a test channel with a watershed on the new nightly * Test the previous Aurora nightly -> watershed -> 54.0b1 update path * Once we're happy with that, set-up a watershed on the real aurora channel, and point the primary aurora update rule at the latest Beta. I'm working on the Gecko patch we'll need for that - it looks pretty straightforward so far. We also need to make some changes to Release Automation to support this. I've filed bug 1353835 for that.

In order to allow Aurora users to install Betas & RCs, we need to do two things: 1) Give them a new update-settings.ini with new ACCEPTED_MAR_CHANNEL_IDS. 2) Give them a new updater that accepts MARs signed with the beta/release cert. This patch should do both of these things. I tested this by: * Building on Try (with a slight modification due to MOZ_UPDATE_CHANNEL differences (https://hg.mozilla.org/try/rev/fe0c28cdb276e11dcf59c66e07346b9df4ae952c & https://hg.mozilla.org/try/rev/f0a82bc58a200915571015505d344b94d05cd9f8) * Updating a current Aurora build to that MAR, which worked fine * Attempting an update to a Beta. This got as far along as it could (passing the MAR certificate check, but failing the version downgrade check). This patch is only intended to land on mozilla-aurora (which dead ends afterwards), so I think the hackyness shouldn't be an issue. One thing I'm not sure of is whether partials will work. Funsize will certainly generate a MAR with update-settings.ini in it, I'm just not sure if the instruction will be correct? I think it will be an ADD instead of PATCH. We may need to tweak something in Funsize to fix that - I'm having trouble finding out where forced files are controlled.

(In reply to Ben Hearsum (:bhearsum) from comment #1) > * Trigger new nightlies manually > * Set-up a test channel with a watershed on the new nightly Callek pointed out that we should make sure we host the watershed nightiles somewhere where they won't get deleted at some point.

Comment on attachment 8855022 [details] [diff] [review] gecko patch to make Aurora users capable of installing Beta & RC updates I think this is fine. Just for my memory, the watershed aurora nightly is still signed with the nightly/aurora key because of the port used in the MOZ_SIGN_CMD, which matches the expectations of the build prior to the watershed. The first beta would be signed with the beta/release/esr key, which matches what the watershed wants. I'm not 100% sure about a partial up to the watershed either, but can't grok what the issue is with PATCH vs ADD for update-settings.ini. It looks like funsize is using make_incremental_update.sh so will get to the file size comparison between bzipped diff and original file at https://hg.mozilla.org/releases/mozilla-aurora/file/default/tools/update-packaging/make_incremental_update.sh#l228 Maybe test on Oak if rstrong/current user there is amenable.

For the shell script the check for forcing an add instruction is in make_incremental_update.sh. It isn't necessary for the complete update since a complete update always has an add instruction for files unless there is an intentional exclusion such as the one you removed for the update-settings.ini file in your patch. I think for the partial it will just create an add instruction anyways since it is no longer excluded after the patch. It would be a "good thing" to make sure that the update-settings.ini file is not added to the precomplete file. I don't think it will be but it is better to be safe than sorry. iirc the certificate to sign Windows binary files is the same for aurora and beta. If not, that will be a problem. There may be issues with this approach on at least Windows since there are numerous places where Aurora is set in the registry during install and during post update. Once the client is migrated over to beta these "aurora" clients are going to have the beta values and I'm not sure if it will clean those up entirely. needinfoing mhowell regarding the previous paragraph.

Comment on attachment 8855022 [details] [diff] [review] gecko patch to make Aurora users capable of installing Beta & RC updates This should be fine from an app update perspective though as always with something that can abandon clients it would be a good thing to verify it works and the update from it works before pushing it to clients.

(In reply to Nick Thomas [:nthomas] from comment #4) > Comment on attachment 8855022 [details] [diff] [review] > gecko patch to make Aurora users capable of installing Beta & RC updates > > I think this is fine. Just for my memory, the watershed aurora nightly is > still signed with the nightly/aurora key because of the port used in the > MOZ_SIGN_CMD, which matches the expectations of the build prior to the > watershed. The first beta would be signed with the beta/release/esr key, > which matches what the watershed wants. That's my understanding too - thanks for spelling it out. > I'm not 100% sure about a partial up to the watershed either, but can't grok > what the issue is with PATCH vs ADD for update-settings.ini. It looks like > funsize is using make_incremental_update.sh so will get to the file size > comparison between bzipped diff and original file at > https://hg.mozilla.org/releases/mozilla-aurora/file/default/tools/update- > packaging/make_incremental_update.sh#l228 Yeah, it looks like this is a non-issue after feedback you and Robert. I think my brain thought that the ADD instruction would fail because update-settings.ini already exists - which obviously isn't the case. > Maybe test on Oak if rstrong/current user there is amenable. Good idea, maybe we can Softvision on it, too.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #5) > It would be a "good thing" to make sure that the update-settings.ini file is > not added to the precomplete file. I don't think it will be but it is better > to be safe than sorry. I just checked my local install, and update-settings.ini is not in precomplete. > iirc the certificate to sign Windows binary files is the same for aurora and > beta. If not, that will be a problem. That's correct.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #5) > There may be issues with this approach on at least Windows since there are > numerous places where Aurora is set in the registry during install and > during post update. Once the client is migrated over to beta these "aurora" > clients are going to have the beta values and I'm not sure if it will clean > those up entirely. I've identified two Windows-only issues: 1) Our entry in the system default browser selection UI (whichever one the particular Windows version has) continues to use the name Developer Edition (but would get its icon updated). 2) All shortcuts continue to use the name Developer Edition (but would also get their icons updated). Other registry entries either already get rewritten correctly by the post-update routine, or they just don't need to change. I assume we want to get both of those issues fixed before this trigger gets pulled. I'll file them both separately and start working on them.

(In reply to Matt Howell [:mhowell] from comment #9) > (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from > comment #5) > > There may be issues with this approach on at least Windows since there are > > numerous places where Aurora is set in the registry during install and > > during post update. Once the client is migrated over to beta these "aurora" > > clients are going to have the beta values and I'm not sure if it will clean > > those up entirely. > > I've identified two Windows-only issues: > 1) Our entry in the system default browser selection UI (whichever one the > particular Windows version has) continues to use the name Developer Edition > (but would get its icon updated). > 2) All shortcuts continue to use the name Developer Edition (but would also > get their icons updated). > > Other registry entries either already get rewritten correctly by the > post-update routine, or they just don't need to change. > > I assume we want to get both of those issues fixed before this trigger gets > pulled. I'll file them both separately and start working on them. Thanks Matt! You probably saw already in comment #0, but this is planned to happen on April 18th.

We talked about this in a meeting yesterday and we're planning to move Aurora users to a repack (not a rebuild) of vanilla Beta. The repack will enable DevEdition things (eg: themes), which means we need to include the partner customizations with the watershed we're already doing for updater.exe and update-settings.ini. The in-product changes needed for this to work will not be ready by the time 54 moves to Beta, so we'll be holding Aurora users at Aurora 54 until they are. We must maintain the ability to ship chemspill fixes to them, so we cannot land anything to the Aurora repository in the meantime. Because of these two things, I no longer think it makes sense to use Aurora to create our watershed MARs. Instead, I intend to do it more or less by hand. The new migration procedure will be roughly as follows: * Freeze Aurora nightlies when 54 uplifts to Beta * When DevEdition customizations are ready, create MARs that contain: ** An update-settings.ini that accepts beta+release MAR_CHANNEL_IDs ** An updater.exe that accepts beta/release mar certificates ** All partner customizations ** Possibly also channel-prefs.js (see below) * Manually sign and host the MARs * Set-up a test channel with a watershed on the new nightly * Test the previous Aurora nightly -> watershed -> 54.0b1 update path * Once we're happy with that, set-up a watershed on the real aurora channel, and point the primary aurora update rule at the latest Beta. In talking with Rail, we realized that if we want existing Aurora users *and* new DevEdition users to be part of the early beta audience, we'll need to change the "aurora" channel name to match the partner repack name. That will be something like "beta-cck-devedition". If we only want former aurora users to be part of early beta, no channel changes are needed.

Is the new dev edition reback build going to be built with the existing dev edition branding? If "Firefox Developer Edition" isn't going to be the branding name anymore, then I need to get bug 1354321 and bug 1354325 uplifted.

Not sure who works on Firefox profiles but I know that on Aurora profiles are handled differently. Just calling this out so project managers are aware and this isn't overlooked.

(In reply to Matt Howell [:mhowell] from comment #12) > Is the new dev edition reback build going to be built with the existing dev > edition branding? If "Firefox Developer Edition" isn't going to be the > branding name anymore, then I need to get bug 1354321 and bug 1354325 > uplifted. I believe it's keeping the same name, per bug 1354262. Might be worth confirming with Bryan Clark or Tom Tromey. (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #13) > Not sure who works on Firefox profiles but I know that on Aurora profiles > are handled differently. Just calling this out so project managers are aware > and this isn't overlooked. Ritu, Rail, Bryan Clark, and I talked about this earlier this week. I think all the work to make this possible in prefs is happening in the aforementioned bug.

I've made significant progress on creating custom watershed mars in the past day. I was able to go from Aurora -> Watershed -> Beta successfully, including keeping the DevEdition branding via the distribution.ini settings. A couple of things came up while doing that: - Do we need a localized updater.exe for the watershed update? Doing this is significantly more work than using the en-US for everybody, but if UI is shown during the first Watershed -> Beta update it could be problematic for localized builds. Note that even if we use the en-US updater for everyone in the Watershed, they will end up with a localized updater after updating to Beta (so any subsequent update UI shown would be localized). - Do we need a separate mar channel id for DevEdition, or can they use firefox-mozilla-beta? My gut says sharing is probably OK, because they are on the same Gecko version anyways. Robert, I'd appreciate any thoughts you have on the above.

(In reply to Matt Howell [:mhowell] from comment #12) > Is the new dev edition reback build going to be built with the existing dev > edition branding? If "Firefox Developer Edition" isn't going to be the > branding name anymore, then I need to get bug 1354321 and bug 1354325 > uplifted. Yes, we want to keep all the existing DevEdition branding. For users who migrate from Aurora to Beta (DevEdition users) we want them to keep their existing DevEdition shortcuts as well. I'm not exactly clear what those other two bugs are doing.

(In reply to Bryan Clark (DevTools PM) [:clarkbw] from comment #16) > Yes, we want to keep all the existing DevEdition branding. For users who > migrate from Aurora to Beta (DevEdition users) we want them to keep their > existing DevEdition shortcuts as well. I'm not exactly clear what those > other two bugs are doing. Okay, thank you. I did those two patches to create support for changing the branding during an update, but I wasn't sure whether we were actually going to be doing that here or keeping it the same. If we're keeping it the same, then there's nothing that needs to be done.

> then there's nothing that needs to be done. I like the sounds of that!

I managed to get the first draft of watershed mars ready today. On all platforms I was able to to go from Aurora -> Watershed, which switched the channel, applied the distribution.ini, and changed the updater/update-settings to enable Beta updates to be installed. On Linux and Windows I was able to further update to a Beta afterwards, which validates the update settings changes made in the watershed. For complicated reasons that I won't get into, we can't verify that on OS X until Beta moves to 54.0. If anyone else wants to give it a try I'd really appreciate it. You'll need to: * Start with 53.0 Aurora build (I suggest https://archive.mozilla.org/pub/firefox/nightly/2017/03/2017-03-01-00-40-03-mozilla-aurora/ or https://archive.mozilla.org/pub/firefox/nightly/2017/03/2017-03-01-08-43-03-mozilla-aurora/) * Change the channel to "aurora-betaswitchtest". ** On Linux and Windows you can do this by editing defaults/pref/channel-prefs.js directly. ** On Mac you can do this by running 'Services.prefs.getDefaultBranch(null).setCharPref("app.update.channel", "aurora-betaswitchtest")' in the Browser context in the Scratchpad Once you've done the above you should get offered the watershed update. You can poke around the appdir to verify that (if you have distribution/distribution.ini, you got it!). On Linux and Windows you should get a second update afterwards that will take you to 53.0 RC. Tomorrow is a holiday for me, but I'll be back at this next week to figure out the next steps.

(In reply to Ben Hearsum (:bhearsum) from comment #15) > I've made significant progress on creating custom watershed mars in the past > day. I was able to go from Aurora -> Watershed -> Beta successfully, > including keeping the DevEdition branding via the distribution.ini settings. > > A couple of things came up while doing that: > - Do we need a localized updater.exe for the watershed update? Doing this is > significantly more work than using the en-US for everybody, but if UI is > shown during the first Watershed -> Beta update it could be problematic for > localized builds. Note that even if we use the en-US updater for everyone in > the Watershed, they will end up with a localized updater after updating to > Beta (so any subsequent update UI shown would be localized). Whether the string are localized for the updater or in the Windows UI for the Maintenance Service both of which are in updater.ini isn't really my call. From a technical perspective it should be ok. > > - Do we need a separate mar channel id for DevEdition, or can they use > firefox-mozilla-beta? My gut says sharing is probably OK, because they are > on the same Gecko version anyways. I think you want them to be the same.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #20) > (In reply to Ben Hearsum (:bhearsum) from comment #15) > > I've made significant progress on creating custom watershed mars in the past > > day. I was able to go from Aurora -> Watershed -> Beta successfully, > > including keeping the DevEdition branding via the distribution.ini settings. > > > > A couple of things came up while doing that: > > - Do we need a localized updater.exe for the watershed update? Doing this is > > significantly more work than using the en-US for everybody, but if UI is > > shown during the first Watershed -> Beta update it could be problematic for > > localized builds. Note that even if we use the en-US updater for everyone in > > the Watershed, they will end up with a localized updater after updating to > > Beta (so any subsequent update UI shown would be localized). > Whether the string are localized for the updater or in the Windows UI for > the Maintenance Service both of which are in updater.ini isn't really my > call. From a technical perspective it should be ok. Ritu, are the right person to make this call?

(In reply to Ben Hearsum (:bhearsum) from comment #15) > - Do we need a localized updater.exe for the watershed update? Doing this is > significantly more work than using the en-US for everybody, but if UI is > shown during the first Watershed -> Beta update it could be problematic for > localized builds. Note that even if we use the en-US updater for everyone in > the Watershed, they will end up with a localized updater after updating to > Beta (so any subsequent update UI shown would be localized). Are users expected to interact with the installer in this phase, or it's just a dialog displayed to users?

(In reply to Francesco Lodolo [:flod] from comment #22) > (In reply to Ben Hearsum (:bhearsum) from comment #15) > > - Do we need a localized updater.exe for the watershed update? Doing this is > > significantly more work than using the en-US for everybody, but if UI is > > shown during the first Watershed -> Beta update it could be problematic for > > localized builds. Note that even if we use the en-US updater for everyone in > > the Watershed, they will end up with a localized updater after updating to > > Beta (so any subsequent update UI shown would be localized). > > Are users expected to interact with the installer in this phase, or it's > just a dialog displayed to users? There's no installer, just an update. I don't *think* any UI will be shown for it in the normal case, but I'm not certain.

The string that is added to the registry will be displayed for the Maintenance Service in Windows Services until the next update. The updater UI is typically not shown for staged updates but it can be seen for this case some of the time. It is typically shown for non staged updates which is significantly lower than staged updates. It is a dialog that is displayed without user interaction.

While doing some update testing today I noticed that on OS X, the Firefox icon and app name changes as soon as the first Beta updated is applied. I go from the blue DevEdition logo + "FirefoxDeveloperEdition" in the top bar to plain Firefox logo + "Firefox" in the top bar. The updated browser continues to use the dark theme and separate profile, however. According to mkaply, the icon and app name cannot be overridden by a partner repack (they are part of files that are included in the update MARs, so each update would override any one-off changes we do). This means that if the DevEdition icon+name are absolute requirements, partner repacks are not a viable solution. The alternative is doing full on binaries for DevEdition, but that may not satisfy RelMan's requirement of using the DevEdition population to test early Betas (at least, we cannot ship them exactly the same bits). Bryan, Ritu - I think I need one or both of you to resolve this because your requirements are incompatible. Partner repacks vs. full builds are very different to implement, so we're going to need to resolve this in short order.

Using full builds would also remove the need for bug 1357161, where we are manually fixing up the icons on Windows.

BTW: you can test by just installing the DMG for the build to see the same affect instead of updating. Update just adds, mods, and deletes files so the end result should be the same as installing the DMG.

Unless we can find another solution a rebuild seems like the necessary option.

(In reply to Ben Hearsum (:bhearsum) from comment #25) > While doing some update testing today I noticed that on OS X, the Firefox > icon and app name changes as soon as the first Beta updated is applied. I go > from the blue DevEdition logo + "FirefoxDeveloperEdition" in the top bar to > plain Firefox logo + "Firefox" in the top bar. The updated browser continues > to use the dark theme and separate profile, however. > > According to mkaply, the icon and app name cannot be overridden by a partner > repack (they are part of files that are included in the update MARs, so each > update would override any one-off changes we do). This means that if the > DevEdition icon+name are absolute requirements, partner repacks are not a > viable solution. The alternative is doing full on binaries for DevEdition, > but that may not satisfy RelMan's requirement of using the DevEdition > population to test early Betas (at least, we cannot ship them exactly the > same bits). > > Bryan, Ritu - I think I need one or both of you to resolve this because your > requirements are incompatible. Partner repacks vs. full builds are very > different to implement, so we're going to need to resolve this in short > order. Lawrence, Catlee said I should include you here, too. If we do full rebuilds we end up with two full release streams (separate builds, separate updates) on mozilla-beta, which probably hase implications for QE.

After much back and forth this week we've settled on a new plan. We're going to create DevEdition builds per-push on mozilla-beta, and enable Release Promotion for them. This means that Release Management will be able start Release Promotion for both Beta and DevEdition as they see fit. This path has fewer unknowns, but it still a substantial amount of work. This plan has a few notable implications: * DevEdition builds will enable unsigned addons and diagnostic asserts (just like they do now on Aurora). * We will continue using the firefox-mozilla-aurora MAR_CHANNEL_ID and nightly signing certificates for DevEdition. We cannot share these with Beta, because it would enable attackers to migrate people from Beta (which doesn't allow unsigned addons) to DevEdition (which does). ** Because of this, we cannot ship RCs to DevEdition users as we do for vanilla Beta. ** Also because of this, we no longer need a watershed update. * DevEdition builds will have their own top level directory on archive.mozilla.org. Ritu has asked that we use https://archive.mozilla.org/pub/devedition-beta/ for this.

I've filed dependent bugs for the parts of CI/Release Promotion that we know we'll need to update. I expect there will be more as we dive into it. It's also notable that testing this sort of change is a very lengthy process - it takes many hours for a complete test (possibly more in this case, because we'll need to test both the new DevEdition paths, and the existing vanilla Beta paths).

(In reply to Ben Hearsum (:bhearsum) from comment #30) > * DevEdition builds will enable unsigned addons and diagnostic asserts (just > like they do now on Aurora). To clarify, does this mean that DevEdition builds will not set the RELEASE_OR_BETA define? Or does it mean they will always have EARLY_BETA_OR_EARLIER set?

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #32) > (In reply to Ben Hearsum (:bhearsum) from comment #30) > > * DevEdition builds will enable unsigned addons and diagnostic asserts (just > > like they do now on Aurora). > > To clarify, does this mean that DevEdition builds will not set the > RELEASE_OR_BETA define? Or does it mean they will always have > EARLY_BETA_OR_EARLIER set? It looks like these have a lot of implications to build configuration. Ritu, Bryan - do either of you have any sense as to whether or not we want these defined for the new DevEdition?

DevEdition can continue to assume a pre-Beta role with build configuration (meaning it doesn't set RELEASE_OR_BETA or could always set EARLY_BETA_OR_EARLIER; whichever is best for developers) . However I've expressed that those build configurations are not blocking the migration. I'm happy to have them role in after we've handled migrating users over to the Beta channel.

(In reply to Bryan Clark (DevTools PM) [:clarkbw] from comment #34) > DevEdition can continue to assume a pre-Beta role with build configuration > (meaning it doesn't set RELEASE_OR_BETA or could always set > EARLY_BETA_OR_EARLIER; whichever is best for developers) So just to be 100% clear: you're happy with any combination of EARLY_BETA_OR_EARLIER and RELEASE_OR_BETA? (They aren't mutually exclusive.)

I'm happy with DevEdition maintaining the role of Aurora and being closer to Nightly. I don't know what the RELEASE_OR_BETA flags are currently setting so I'm not sure how to answer that question, but in general I think this is what DevEdition was doing previously so I believe it should be ok to maintain that.

It sounds like we're saying: EARLY_BETA_OR_EARLIER = true RELEASE_OR_BETA = false for all Dev Edition builds then? That would seem to make it be the closest to Nightly. (It would be great to update https://wiki.mozilla.org/Platform/Channel-specific_build_defines once an approach is chosen for the flags with the new Dev Edition.)

> EARLY_BETA_OR_EARLIER = true > RELEASE_OR_BETA = false I'll mention one more just for the sake of completeness: NIGHTLY_BUILD = false This combination of the three flags is precisely what the aurora channel has today. (IMO it's neither closer to nightly nor beta.) I think it's reasonable to try keeping these values at first. It may turn out to be an excellent compromise ("We still have the four builds, but now my code ships faster!") or it may turn out to be confusing ("I can't reason about these mozilla-beta bugs."). If the latter then we could always revisit the RELEASE_OR_BETA decision.

1) We would like to push the DevEd build to an early beta audience as part of the Beta staged rollout. This is needed to stabilize quality and crash rates before pushing beta builds to 100% of beta end-usres. 2) Early_beta_or_earlier flag is used by relmgmt team to turn off features post beta4. While 1 & 2 both use a notion of "early beta" but they are serving different goals. I'd prefer it if early_beta flag for DevEd builds mimicks the early_beta flag on regular Beta builds to be consistent. Hi Sylvestre, could you also please weigh in on this one?

Agreed with Ritu. I think after beta 4 or 5, we should have devedition matching as much as possible the normal beta. With this flag enabled for dev edition and not beta (and therefor potential features), it is going to make the life harder for anyone in RM, metrics, releng (because we will have the same flag having different meaning for beta & beta devedition), etc. To summarize, devedition should be the same as regular beta wrt to these flags, with just a define being IS_IT_A_DEVEDITION_BETA_VERSION (mostly for the diagnostic assert)

And of course, we can revaluate that after 57.

FWIW, early Beta currently gets diagnostic asserts via EARLY_BETA_OR_EARLIER [1], so if we just want DevEd to match Beta as much as possible there's no need to introduce anything new. If we want DevEd to get diagnostic asserts all throughout the cycle, then keeping EARLY_BETA_OR_EARLIER set on every DevEd build is enough for that. This does mean that having both NIGHTLY_BUILD and RELEASE_OR_BETA becomes redundant, since there will no longer be any builds where we set neither. The main disadvantage of losing this 3rd option, in my personal opinion, is that some crashes don't really show up in our Nightly audience with nearly the same frequency. Sometimes it takes more than a MOZ_DIAGNOSTIC_ASSERT to catch these crashes early. But perhaps in the new world, we just need to take advantage of EARLY_BETA_OR_EARLIER in those cases. [1] https://dxr.mozilla.org/mozilla-central/source/mfbt/Assertions.h?q=MOZ_DIAGNOSTIC_ASSERT&redirect_type=direct#447

(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #42) > FWIW, early Beta currently gets diagnostic asserts via EARLY_BETA_OR_EARLIER > [1] Nope, I asked for a backout earlier today: https://bugzilla.mozilla.org/show_bug.cgi?id=1357799#c21 I wrote the initial patch when we were still working on the repack idea (ie same binary), as it is no longer the case, we don't have to use this workaround.

(In reply to Sylvestre Ledru [:sylvestre] from comment #43) > (In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #42) > > FWIW, early Beta currently gets diagnostic asserts via EARLY_BETA_OR_EARLIER > > [1] > Nope, I asked for a backout earlier today: > https://bugzilla.mozilla.org/show_bug.cgi?id=1357799#c21 > > I wrote the initial patch when we were still working on the repack idea (ie > same binary), as it is no longer the case, we don't have to use this > workaround. So that patch makes diagnostic asserts enabled for any build that doesn't set RELEASE_OR_BETA, if I'm reading correctly. To summarize everything, it sounds like we need to: * Set EARLY_BETA_OR_EARLIER the same for DevEdition that we do for vanilla Beta. (This will happen for free, because it's a hardcoded setting in the tree) * Ensure that RELEASE_OR_BETA is not set for DevEdition.

We will be changing the channel at some point (https://bugzilla.mozilla.org/show_bug.cgi?id=1373164), but the Dawn project itself has been completed. Thanks to everyone who was involved (there were a lot of you!).