Closed Bug 841903 Opened 11 years ago Closed 11 years ago

thunderbird release channel releases pull branch settings from the wrong place

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: jhopkins)

References

Details

Attachments

(1 file, 1 obsolete file)

eg bug 841898, where it turned pymake on because it looked at "comm-release"'s branch config instead of comm-esr17's.
Blocks: 841898
Assignee: nobody → jhopkins
I would argue that Thunderbird mainstream release builds _should_ be looking at the comm-release branch config.  The issue was that the comm-release config's enable_pymake setting should have been disabled, not that we were looking in the wrong place for it.
Flags: needinfo?(bhearsum)
(In reply to John Hopkins (:jhopkins) from comment #1)
> I would argue that Thunderbird mainstream release builds _should_ be looking
> at the comm-release branch config.  The issue was that the comm-release
> config's enable_pymake setting should have been disabled, not that we were
> looking in the wrong place for it.

There's no facility for disabling pymake only for release builds, nor should there be. We purposely inherit from the branch config to ensure consistency with the equivalent nightly builds. Maybe the root problem here is that we don't *have* equivalent nightly builds for comm-release's ESR17 based release builds?
Flags: needinfo?(bhearsum)
The more I think about this the more strongly I feel that we either need to:
a) change comm-release to look at mozilla-esr17/comm-esr17
b) setup a new branch in buildbot that does, and create a release config for it

We shouldn't be shipping releases without CI on them. comm-esr17's CI isn't enough because of the problems with branch settings described here.
yea the root problem is that comm-release is based on Gecko > 17, (and should stay around, with builds based on gecko > 17 imho)

(In reply to Ben Hearsum [:bhearsum] from comment #3)
> The more I think about this the more strongly I feel that we either need to:
> a) change comm-release to look at mozilla-esr17/comm-esr17
> b) setup a new branch in buildbot that does, and create a release config for
> it
> 
> We shouldn't be shipping releases without CI on them. comm-esr17's CI isn't
> enough because of the problems with branch settings described here.

Given this I would recommend we go with b, and leave comm-release around (since community :-) ). We can mark comm-release branch priority as low as try imho though, but have "something" that lets us build a 17.0.x non-esr based on the esr code, using the config we intend.
I just confirmed with standard8 that Thunderbird does not need to build against the comm-release repo anymore.

Therefore what we need to change is have the 'comm-release' branch config point at comm-esr17 and have its other settings match the 'comm-esr17' branch config settings (enable_pymake, etc...).  Basically, bhearsum's option (a) in comment 3 + the other config changes.
(In reply to Ben Hearsum [:bhearsum] from comment #3)
> The more I think about this the more strongly I feel that we either need to:
> a) change comm-release to look at mozilla-esr17/comm-esr17

(In reply to John Hopkins (:jhopkins) from comment #5)
> ... Basically, bhearsum's option (a) in comment 3 + the other config changes.

Despite my other opinions/comments around this bug, I will block strongly on this.

We can't (imho) have "comm-release" in TBPL/Configs/Etc. not pay attention to comm-release. Far too much confusion potentional, to us community, sheriffs, etc.

So even if we agree its a good thing to drop comm-release (which I disagree with) we should create a new "TBPL"/"Buildbot" branch name for this.

to make this bug actionable can we agree to do b) and defer a) to another conversation/day?
I disagree. Thunderbird's release channel is shipping off of ESR17 repos. Given that, it makes sense for the "Thunderbird-Release" tree to track esr17 repositories.
Callek: Can you please set up a meeting with the necessary stakeholders so we can unblock progress on this bug?  Thanks.
Flags: needinfo?(bugspam.Callek)
Just discussed on IRC:

While I do feel strongly on my opinion here, -- I should note two thing real quick
(a) I forgot we named the branch in tbpl "Thunderbird-Release" vs "comm-release"
(b) I don't forsee discussion persuading my opinion, with the foreknowledge that it is only an opinion.

so since jhopkins and bhearsum at least are of similar opinion and I don't see anyone else believing as I do, I'm ok with making the change, provided "someone" changes TBPL to watch things properly as well.  [TBPL to track comm-esr17 instead of comm-release for displayed csets, treeclosure dispay, etc.]

So I am unblocking myself from this bug:
Basically I agree we can't just stall this bug out due to differing opinion. Since I seem to be the sole opinion holder of my thought, I don't think its productive to delay longer, or even require a manager call, when two others of releng agree
Flags: needinfo?(bugspam.Callek)
John, any progress here? We're almost halfway to the next release. This needs to get addressed soon so we're not scrambling at the last minute.
bhearsum: it's next on my list of things to do (say, by EOW).  I did make some progress but it will need testing.  I don't want to block so if it needs doing today then please feel free to reassign.
Attachment #722400 - Flags: feedback?(bhearsum)
Comment on attachment 722400 [details] [diff] [review]
[buildbot-configs] align comm-release settings with comm-esr17

Review of attachment 722400 [details] [diff] [review]:
-----------------------------------------------------------------

This looks like it will work.
Attachment #722400 - Flags: feedback?(bhearsum) → feedback+
Attachment #722400 - Flags: feedback+ → feedback?(mbanner)
Comment on attachment 722400 [details] [diff] [review]
[buildbot-configs] align comm-release settings with comm-esr17

Review of attachment 722400 [details] [diff] [review]:
-----------------------------------------------------------------

::: mozilla/thunderbird_config.py
@@ +707,1 @@
>  BRANCHES['comm-release']['update_channel'] = 'release'

If we enable nightly builds (see below), I'd like this changed. Something like nightly-release, just to be doubly sure we don't mess things up.

@@ +731,2 @@
>  # temp disable nightlies (which includes turning off enable_l10n and l10nNightlyUpdate)
> +BRANCHES['comm-release']['enable_nightly'] = True

Do we really want to enable nightly builds here? Doing so will mean we have two sets of nightlies (from buildbot branches comm-esr17 and comm-release) that are practically the same.

I know there could be a few differences in branding or other buildbot changes, but I'm not sure the trade off is worth it.

If we do, we definitely don't want l10n builds.
(In reply to Mark Banner (:standard8) from comment #14)
> Comment on attachment 722400 [details] [diff] [review]
> [buildbot-configs] align comm-release settings with comm-esr17
> 
> Review of attachment 722400 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: mozilla/thunderbird_config.py
> @@ +707,1 @@
> >  BRANCHES['comm-release']['update_channel'] = 'release'
> 
> If we enable nightly builds (see below), I'd like this changed. Something
> like nightly-release, just to be doubly sure we don't mess things up.
> 
> @@ +731,2 @@
> >  # temp disable nightlies (which includes turning off enable_l10n and l10nNightlyUpdate)
> > +BRANCHES['comm-release']['enable_nightly'] = True
> 
> Do we really want to enable nightly builds here? Doing so will mean we have
> two sets of nightlies (from buildbot branches comm-esr17 and comm-release)
> that are practically the same.
> 
> I know there could be a few differences in branding or other buildbot
> changes, but I'm not sure the trade off is worth it.
> 
> If we do, we definitely don't want l10n builds.

I don't think there's any reason to enable nightlies. IMO we just need to point the dep builds at the right repos so that we're testing what we'll go to build with.
Comment on attachment 722400 [details] [diff] [review]
[buildbot-configs] align comm-release settings with comm-esr17

I'm going to take another pass on this, given some of the confusion around nightlies.
Attachment #722400 - Flags: feedback?(bhearsum)
Comment on attachment 722400 [details] [diff] [review]
[buildbot-configs] align comm-release settings with comm-esr17

Review of attachment 722400 [details] [diff] [review]:
-----------------------------------------------------------------

::: mozilla/thunderbird_config.py
@@ +707,4 @@
>  BRANCHES['comm-release']['update_channel'] = 'release'
> +BRANCHES['comm-release']['mozilla_dir'] = 'mozilla'
> +BRANCHES['comm-release']['skip_blank_repos'] = True
> +BRANCHES['comm-release']['call_client_py'] = True

It's curious to me these weren't set before, but it seems like they should be...it makes me wonder if these builds ever worked.

@@ +732,5 @@
> +BRANCHES['comm-release']['enable_nightly'] = True
> +BRANCHES['comm-release']['create_snippet'] = True
> +BRANCHES['comm-release']['create_partial'] = True
> +BRANCHES['comm-release']['aus2_base_upload_dir'] = '/opt/aus2/incoming/2/Thunderbird/comm-release'
> +BRANCHES['comm-release']['aus2_base_upload_dir_l10n'] = '/opt/aus2/incoming/2/Thunderbird/comm-release'

Per Mark's comment and discussion elsewhere, we shouldn't enable nightlies at all.
This patch does not enable nightlies.
Attachment #722400 - Attachment is obsolete: true
Attachment #722400 - Flags: feedback?(mbanner)
Attachment #722400 - Flags: feedback?(bhearsum)
Attachment #727745 - Flags: review?(bhearsum)
Attachment #727745 - Flags: review?(bhearsum) → review+
Comment on attachment 727745 [details] [diff] [review]
[buildbot-configs] updated patch

Landed in https://hg.mozilla.org/build/buildbot-configs/rev/bb1de9407009
Attachment #727745 - Flags: checked-in+
In production
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: