Build Thunderbird 38 betas from mozilla-release

RESOLVED WORKSFORME

Status

defect
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: rkent, Assigned: rkent)

Tracking

38 Branch

Thunderbird Tracking Flags

(thunderbird38+ fixed, thunderbird39 unaffected, thunderbird40 unaffected)

Details

Attachments

(1 attachment)

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: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.