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)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: jhopkins)
References
Details
Attachments
(1 file, 1 obsolete file)
4.24 KB,
patch
|
bhearsum
:
review+
jhopkins
:
checked-in+
|
Details | Diff | Splinter Review |
eg bug 841898, where it turned pymake on because it looked at "comm-release"'s branch config instead of comm-esr17's.
Reporter | ||
Updated•11 years ago
|
Assignee: nobody → jhopkins
Assignee | ||
Comment 1•11 years ago
|
||
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)
Reporter | ||
Comment 2•11 years ago
|
||
(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)
Reporter | ||
Comment 3•11 years ago
|
||
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.
Comment 4•11 years ago
|
||
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.
Assignee | ||
Comment 5•11 years ago
|
||
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.
Comment 6•11 years ago
|
||
(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?
Reporter | ||
Comment 7•11 years ago
|
||
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.
Assignee | ||
Comment 8•11 years ago
|
||
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)
Comment 9•11 years ago
|
||
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)
Reporter | ||
Comment 10•11 years ago
|
||
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.
Assignee | ||
Comment 11•11 years ago
|
||
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.
Assignee | ||
Comment 12•11 years ago
|
||
Attachment #722400 -
Flags: feedback?(bhearsum)
Reporter | ||
Comment 13•11 years ago
|
||
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+
Assignee | ||
Updated•11 years ago
|
Attachment #722400 -
Flags: feedback+ → feedback?(mbanner)
Comment 14•11 years ago
|
||
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.
Reporter | ||
Comment 15•11 years ago
|
||
(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.
Reporter | ||
Comment 16•11 years ago
|
||
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)
Reporter | ||
Comment 17•11 years ago
|
||
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.
Assignee | ||
Comment 18•11 years ago
|
||
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)
Reporter | ||
Updated•11 years ago
|
Attachment #727745 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 19•11 years ago
|
||
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+
Assignee | ||
Comment 20•11 years ago
|
||
In production
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•