395954 - Can Release build process generate build tinder-configs from default tinder-configs

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P3)

Description

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Currently, we bring forward a version of tinder-config from a release branch, and
manually merge in any changes from what is used for nightlies.

Can we just use what is in nightly, and not manually change/update anything?

This is a similar question to bug#386338

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Some intentional differences discussed yesterday in IRC include:

1) mk_add_options MOZ_MAKE_FLAGS="-j1"
Build uses this because it seems to be more stable

2) codesighs is not part of released product:
< mk_add_options MOZ_CO_MODULE="mozilla/tools/update-packaging"
> mk_add_options MOZ_CO_MODULE="mozilla/tools/update-packaging mozilla/tools/codesighs"
> ac_add_options --enable-codesighs

3) Different update channels:
< ac_add_options --enable-update-channel=beta
> ac_add_options --enable-update-channel=nightly

4) different branding:
> #ac_add_options --enable-glitz
< ac_add_options --with-branding=browser/branding/unofficial

Comment 2

[Robert Helmer [:rhelmer]]

We could have a "basic" config and then a set of overrides on top of that.. I don't see any simple way to automate that (that is, without knowing a valid override for every possible setting, which isn't very realistic).

Then we'd only need to compare the overrides against eachother. That might make our lives a little simpler but it doesn't seem worth the effort at this time IMHO; you'd still need to compare the override files every release, and "diff" gives us basically the same result.

It might be better (to start) to automatically detect differences, and then notify that these files need to be merged.

Comment 3

[J. Paul Reed [:preed]]

The answer to this bug summary (and bug 386338) is "No, they cannot."

As rhelmer said above (and over in bug 386338), there are certain differences between nightlies and release that must be maintained (directory milestones in the tinder configs, update channels, etc.)

As bsmedberg points out, we could put logic into the mozconfig (and tinder-config, I suppose), but that would put logic into files that have traditionally been configuration-specific.

I think two things will help this problem:

1. When 379278 is fixed, we can use the TinderConfig steps to automate much of the configuration churn.

2. rhelmer's idea of looking for differences in the configs is a good one; I think one of the things that would help would be to standardize the configuration order, so the diffs are actually easy to eyeball.

I think putting programmatic logic into (traditionally) configuration-only files is a recipe for confusion, and thus disaster.

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

What about:

1) adding the four settings in Comment#1 to bootstrap cfg. 

2) Adding step in the build process which reads the default tinder-configs, and does search-and-replace of whatever is specified in bootstrap cfg to generate the build tinder-configs?

It seems like a short list, with well known substitution value pairs, all very sed-able, and I believe (without proof) that this would be better then the current manual-diff-and-edit approach.

$0.02.

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

3) It might be useful to also diff the newly generated build tinder-configs with the build tinder-configs used in the last release, and flag any differences that happened. 

Unclear if that would be an error condition or not, but certainly, it would be worth a human to review, in case the changes impact the newly-started build

Comment 6

[[e-mail] (:bhearsum)]

(In reply to comment #4)
> What about:
>
> 2) Adding step in the build process which reads the default tinder-configs, and
> does search-and-replace of whatever is specified in bootstrap cfg to generate
> the build tinder-configs?

This happens during the 'TinderConfig' step of Bootstrap.

> 3) It might be useful to also diff the newly generated build tinder-configs
> with the build tinder-configs used in the last release, and flag any
> differences that happened. 

Personally, I'm indifferent to whether or not we do this. However, if we choose not to I think this bug can be closed.

Comment 7

[Robert Helmer [:rhelmer]]

I agree, we should WONTFIX this and focus on removing tinderbox as a dependency for building. tinder-config variations are a one-time hit, and it's pretty reasonable stuff.

Now that we can bump both nightly and production tinder-config.pl files via bootstrap, I think the issue has been sufficiently mitigated. 

Comment 8

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #7)
> I agree, we should WONTFIX this and focus on removing tinderbox as a dependency
> for building. tinder-config variations are a one-time hit, and it's pretty
> reasonable stuff.
> 
> Now that we can bump both nightly and production tinder-config.pl files via
> bootstrap, I think the issue has been sufficiently mitigated. 
> 
+1. Closed as WONTFIX.