On 04/18/13 04:03 PM, Lukas Blakk wrote: > Hello, > > I'm following up on an action from our Firefox 20 Post-Mortem where it was > discussed that it would be helpful to have a way to pref on a set of features > that want to be in early Beta builds to garner feedback and audience reach > but should not ship since they are not ready for public consumption. > > Briefly reaching out on #developers identified that we could use a > pre-processing flag in mozconfigs for early betas, something like #ifdef > EARLY_BETA_ONLY_FEATURE in which case it seems to me the actions needed would > be: > > * Create and publicize to engineering & product teams the location for > listing feature prefs that need enabling in early beta, but should not ship > * Create the EARLY_BETA_ONLY_FEATURE flag and make sure it enables those > prefs accordingly until we no longer include them in later beta mozconfigs > * Releng automation to switch/edit mozconfigs for earlier betas to check for > this flag
RelEng doesn't have any mozconfigs anymore...they're all in tree (eg: https://hg.mozilla.org/releases/mozilla-beta/file/e3ff97187d14/browser/config/mozconfigs/win32/nightly). I don't want to be stop energy - because I do like this idea - but I don't think RelEng automation should be responsible for dealing with this flag. Just like any other change that affects the build, we need a cycle of dep builds on it before we build a release - which means release automation can't be making the change. If we don't have this landed ahead of time we have no guarantee that the build will succeed with those features disabled. I think that we should use the existing mozconfigs, and modify them after the last beta that we want early beta features in. Then we'll get a cycle of builds with the new configuration and be assured that the release will go smoothly. - Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
