Closed Bug 1157437 Opened 6 years ago Closed 5 years ago

Build Thunderbird 38 betas from mozilla-release

Categories

(Thunderbird :: Build Config, defect)

38 Branch
defect
Not set
normal

Tracking

(thunderbird38+ fixed, thunderbird39 unaffected, thunderbird40 unaffected)

RESOLVED WORKSFORME
Tracking Status
thunderbird38 + fixed
thunderbird39 --- unaffected
thunderbird40 --- unaffected

People

(Reporter: rkent, Assigned: rkent)

Details

Attachments

(1 file)

Firefox has a funny plan going on, where they have the future mozilla-esr38 in mozilla-release while the future Firefox 38.0.5 is in mozilla-beta (which will not merge to mozilla-esr38)

So we need to build Thunderbird betas for TB 38 from mozilla-release and not from mozilla-beta.

I think that the correct way to do that will be to adjust the default mozilla repo in client.py to be mozilla-release instead of mozilla-beta. Any comments?

I note that this would break Standard8's standard release update scripts which scan for mozilla-beta in client.py and update that.
Like this.
Assignee: nobody → rkent
Status: NEW → ASSIGNED
Attachment #8596170 - Flags: feedback?(standard8)
Attachment #8596170 - Flags: feedback?(bugspam.Callek)
http://hg.mozilla.org/releases/comm-beta/rev/a51d522f9e84

Let's test it.

I added tracking flags because this would break Standard8's normal scripts, so I think we will need to be careful at tb-esr38 to make sure this gets corrected.
I suspect this will break/confuse the release process. Since repo locations and such are hard coded aiui
This beta run https://treeherder.mozilla.org/#/jobs?repo=comm-beta&revision=a51d522f9e84 from mozilla-release looks OK, pulled mozilla-release correctly. Anything else that needs testing here?
FWIW my concern with release process is that said process pulls the hard coded repo, at the cset we specify (note: the cset we specify won't exist on m-beta for an m-r cset, or c-release for a c-beta cset depending on which process we use).

Also the process tags the pulled repo at that cset then expects the tag to exist for future operations, e.g. the client.py co --mozilla-revision <TAG> will fail...
Comment on attachment 8596170 [details] [diff] [review]
Change mozilla-beta to mozilla-release in client.py

The builders use a different configuration to what we do here. Like Callek says its likely tagging may fail.

However, I also don't see how Firefox are managing to do this (although I guess they may not have just yet...), Rail probably knows more.
Attachment #8596170 - Flags: feedback?(standard8) → feedback?(rail)
Given the issues, I suppose the best choice is just to continue building Thunderbird 38 from the mozilla-beta repo, even though it will differ slightly from our final build. I expect that we will try to ship at least one beta after the move to comm-esr38 anyway. Or perhaps the obstacles will get sorted by the Firefox folks. So I'll backout that patch on beta, at least for the next beta.
Tagging doesn't use client.py. To make everything work properly the repo set in client.py should be used in ship-it. I think, that's all we need to tweak.
Attachment #8596170 - Flags: feedback?(rail) → feedback+
Comment on attachment 8596170 [details] [diff] [review]
Change mozilla-beta to mozilla-release in client.py

Backed out, at least for beta 3.

https://hg.mozilla.org/releases/comm-beta/rev/bf0dedb2ec0d
Attachment #8596170 - Flags: feedback?(bugspam.Callek)
Everything is now pretty much back to normal, so nothing more will happen with this bug.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.