Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: new build-time defines for controlling when features ship
36 views
Skip to first unread message
Benjamin Smedberg
May 17, 2013, 11:29:42 AM5/17/13
to Gavin Sharp, dev-pl...@lists.mozilla.org, Firefox Dev
On 5/16/2013 8:04 PM, Gavin Sharp wrote:
> Bug 853071 landed in the Firefox 23 cycle, adding some defines that
> make it possible to control when in the release cycle code is built.
>
> I've described the various defines here:
>
> https://wiki.mozilla.org/Platform/Channel-specific_build_defines
My understanding of this is that we were going to limit use of all of
these options to control preference-flipping. In particular I'm worried
about build bustage that is only discovered at channel-uplift time.
>
> EARLY_BETA_OR_EARLIER is defined depending on the corresponding value
> in build/defines.sh. This file is managed manually by the release
> management team, with the variable being cleared once we're past the
> "early beta" point in the release cycle.
As I remember our discussion about this, use of this flag needs explicit
approval from release drivers, and it should not be used as general
testing mechanism. Is this still correct, and should we note this both
in the wiki and in the configure script which sets it?
--BDS
> Bug 853071 landed in the Firefox 23 cycle, adding some defines that
> make it possible to control when in the release cycle code is built.
>
> I've described the various defines here:
>
> https://wiki.mozilla.org/Platform/Channel-specific_build_defines
My understanding of this is that we were going to limit use of all of
these options to control preference-flipping. In particular I'm worried
about build bustage that is only discovered at channel-uplift time.
>
> EARLY_BETA_OR_EARLIER is defined depending on the corresponding value
> in build/defines.sh. This file is managed manually by the release
> management team, with the variable being cleared once we're past the
> "early beta" point in the release cycle.
As I remember our discussion about this, use of this flag needs explicit
approval from release drivers, and it should not be used as general
testing mechanism. Is this still correct, and should we note this both
in the wiki and in the configure script which sets it?
--BDS
Gavin Sharp
May 17, 2013, 11:36:07 AM5/17/13
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
[redirecting this to dev-platform only]
On Fri, May 17, 2013 at 8:29 AM, Benjamin Smedberg <benj...@smedbergs.us>wrote:
> On 5/16/2013 8:04 PM, Gavin Sharp wrote:
>
>> Bug 853071 landed in the Firefox 23 cycle, adding some defines that make
>> it possible to control when in the release cycle code is built.
>>
>> I've described the various defines here:
>>
>> https://wiki.mozilla.org/**Platform/Channel-specific_**build_defines<https://wiki.mozilla.org/Platform/Channel-specific_build_defines>
problem in practice, and I don't think preference flipping is sufficient to
cover all the use cases (some things can't be easily/cleanly
pref-controlled). If I'm wrong about that we can revisit automated
solutions to detecting bustage earlier.
As I remember our discussion about this, use of this flag needs explicit
> approval from release drivers, and it should not be used as general testing
> mechanism. Is this still correct, and should we note this both in the wiki
> and in the configure script which sets it?
>
I think this is correct. I added a note in the wiki, adding a note to the
configure script doesn't seem useful because I think it's unlikely that
users will see it.
Gavin
On Fri, May 17, 2013 at 8:29 AM, Benjamin Smedberg <benj...@smedbergs.us>wrote:
> On 5/16/2013 8:04 PM, Gavin Sharp wrote:
>
>> Bug 853071 landed in the Firefox 23 cycle, adding some defines that make
>> it possible to control when in the release cycle code is built.
>>
>> I've described the various defines here:
>>
>>
>
> My understanding of this is that we were going to limit use of all of
> these options to control preference-flipping. In particular I'm worried
> about build bustage that is only discovered at channel-uplift time.
As mentioned in the firefox-dev thread, I don't expect this to be a serious
>
> My understanding of this is that we were going to limit use of all of
> these options to control preference-flipping. In particular I'm worried
> about build bustage that is only discovered at channel-uplift time.
problem in practice, and I don't think preference flipping is sufficient to
cover all the use cases (some things can't be easily/cleanly
pref-controlled). If I'm wrong about that we can revisit automated
solutions to detecting bustage earlier.
As I remember our discussion about this, use of this flag needs explicit
> approval from release drivers, and it should not be used as general testing
> mechanism. Is this still correct, and should we note this both in the wiki
> and in the configure script which sets it?
>
configure script doesn't seem useful because I think it's unlikely that
users will see it.
Gavin
Gavin Sharp
May 24, 2013, 2:03:40 PM5/24/13
to dev-pl...@lists.mozilla.org, Firefox Dev
One thing I forgot to mention explicitly but that is worth following
up on: we should generally be striving to get rid of code that is
enabled/disabled based on the value of MOZ_UPDATE_CHANNEL. If you are
responsible for any such code, please file bugs to switch them to
using these build defines, wherever possible (and where not possible,
file a bug to investigate adding a define that better addresses the
specific use case). Bug 875342 is one such example.
Gavin
On Thu, May 16, 2013 at 5:04 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
> Bug 853071 landed in the Firefox 23 cycle, adding some defines that make it
> possible to control when in the release cycle code is built.
>
> I've described the various defines here:
>
> https://wiki.mozilla.org/Platform/Channel-specific_build_defines
>
> To recap:
>
> NIGHTLY_BUILD is defined when milestone.txt contains "a1", i.e. for
> mozilla-central builds.
>
> RELEASE_BUILD is defined when milestone.txt does not contain "a", i.e. for
> builds off of mozilla-beta or mozilla-release.
> (autoconf/makefiles).
>
> (RELEASE_BUILD existed previously, but was only defined in pref files. It's
> now "global".)
>
> Gavin
>
> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
up on: we should generally be striving to get rid of code that is
enabled/disabled based on the value of MOZ_UPDATE_CHANNEL. If you are
responsible for any such code, please file bugs to switch them to
using these build defines, wherever possible (and where not possible,
file a bug to investigate adding a define that better addresses the
specific use case). Bug 875342 is one such example.
Gavin
On Thu, May 16, 2013 at 5:04 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
> Bug 853071 landed in the Firefox 23 cycle, adding some defines that make it
> possible to control when in the release cycle code is built.
>
> I've described the various defines here:
>
>
> To recap:
>
> NIGHTLY_BUILD is defined when milestone.txt contains "a1", i.e. for
> mozilla-central builds.
>
> RELEASE_BUILD is defined when milestone.txt does not contain "a", i.e. for
> builds off of mozilla-beta or mozilla-release.
>
> EARLY_BETA_OR_EARLIER is defined depending on the corresponding value in
> build/defines.sh. This file is managed manually by the release management
> team, with the variable being cleared once we're past the "early beta" point
> in the release cycle.
>
> All of these defines are both AC_DEFINE (preprocessors) and AC_SUBSTed
> EARLY_BETA_OR_EARLIER is defined depending on the corresponding value in
> build/defines.sh. This file is managed manually by the release management
> team, with the variable being cleared once we're past the "early beta" point
> in the release cycle.
>
> (autoconf/makefiles).
>
> (RELEASE_BUILD existed previously, but was only defined in pref files. It's
> now "global".)
>
> Gavin
>
> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
Mark Finkle
May 24, 2013, 3:31:18 PM5/24/13
to Gavin Sharp, Benjamin Smedberg, dev-pl...@lists.mozilla.org
> >> I've described the various defines here:
> >>
> >>
> >> https://wiki.mozilla.org/**Platform/Channel-specific_**build_defines<https://wiki.mozilla.org/Platform/Channel-specific_build_defines>
> >>
> >
> > My understanding of this is that we were going to limit use of all
> > of
> > these options to control preference-flipping. In particular I'm
> > worried
> > about build bustage that is only discovered at channel-uplift time.
> As mentioned in the firefox-dev thread, I don't expect this to be a
> serious
> problem in practice, and I don't think preference flipping is
> sufficient to
> cover all the use cases (some things can't be easily/cleanly
> pref-controlled). If I'm wrong about that we can revisit automated
> solutions to detecting bustage earlier.
And we need this on the Android side too. That code is not easily handled via "preference flipping" since the code is native Java.
> >>
> >
> > My understanding of this is that we were going to limit use of all
> > of
> > these options to control preference-flipping. In particular I'm
> > worried
> > about build bustage that is only discovered at channel-uplift time.
> As mentioned in the firefox-dev thread, I don't expect this to be a
> serious
> problem in practice, and I don't think preference flipping is
> sufficient to
> cover all the use cases (some things can't be easily/cleanly
> pref-controlled). If I'm wrong about that we can revisit automated
> solutions to detecting bustage earlier.
0 new messages