Closed Bug 913197 (comm-esr24) Opened 8 years ago Closed 8 years ago

create comm-esr24 branch

Categories

(Release Engineering :: General, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nthomas, Assigned: rail)

References

Details

Attachments

(6 files, 2 obsolete files)

Like bug 796997, only for esr24 if we require it. Depends on discussions about how we are going to handle esr vs release for Thunderbird in future.
(In reply to Nick Thomas [:nthomas] from comment #0)
> Like bug 796997, only for esr24 if we require it. Depends on discussions
> about how we are going to handle esr vs release for Thunderbird in future.

I note SeaMonkey will continue to use comm-release in perpetuity, which will continue to migrate along with the respective trains.

So if TB is forgoing Firefox-release matching gecko versions in favor of 24, we'll indeed need comm-esr24
Alias: comm-esr24
Depends on: 913291
Assignee: nobody → rail
Depends on: mozilla-esr24
Summary: (maybe) create comm-esr24 branch → create comm-esr24 branch
Attached patch configs (obsolete) — Splinter Review
Basically synced with comm-beta and removed enable_multi_locale which is mobile only.
Attachment #800758 - Flags: review?(jhopkins)
Depends on: 913451
Depends on: 913452
Depends on: 913453
Comment on attachment 800758 [details] [diff] [review]
configs

r+ with one correction needed:

 # MERGE DAY - gstreamer-devel packages ride the trains (bug 881589)
 # MERGE DAY - remove branches from this list when gecko 24 merges into them.
-for b in ("comm-release", "comm-esr17"):
+for branch in ["comm-esr17"]:
     for p, pc in BRANCHES[b]['platforms'].items():
         if 'mock_packages' in pc:

'b' was changed to 'branch' in the for..loop but not changed inside the loop.
Attachment #800758 - Flags: review?(jhopkins) → review+
Attached patch configsSplinter Review
fixed patch, carry on r=jhopkins
Attachment #800758 - Attachment is obsolete: true
Attachment #800780 - Flags: review+
No need to add new graph server entries since the branch will be used only for TB 24 release, no need for esr24 CI and release branches.
Depends on: 913287
No longer depends on: mozilla-esr24
in production
> -BRANCHES['comm-beta']['platforms']['linux']['slave_platforms'] = ['fedora']
> -BRANCHES['comm-beta']['platforms']['linux64']['slave_platforms'] = ['fedora64']

This is a noop (I checked the config dump diff) since this branch is not in the FEDORA_REV3_BRANCHES list.

> +BRANCHES['comm-release']['repo_path'] = "releases/comm-esr24"

<rail> Standard8: I'm confused a little bit with the current situation... looks like https://tbpl.mozilla.org/?tree=Thunderbird-Release is not related to release builds, because CI uses comm-release. Should I go ahead and create comm-esr24 CI branch so it corresponds to releases? 
<rail> or should we switch comm-release CI to use comm-esr24 branch?
<Standard8> rail-lunch: yeah we could kill whatever comm-release is and have just comm-esr24 (or whatever you want to do)
Attachment #800876 - Flags: review?(jhopkins)
Comment on attachment 800876 [details] [diff] [review]
mozilla-tests config changes

r+ with one suggestion.  IIRC, we want to keep ESR17 around for a couple of updates after TB24 merges in so the comment below should be changed to reflect that.

+# MERGE DAY: Remove comm-esr17 when TB 24 merges in.
+WIN32_REV3_BRANCHES = ["comm-esr17"]
Attachment #800876 - Flags: review?(jhopkins) → review+
(In reply to John Hopkins (:jhopkins) from comment #9)
> Comment on attachment 800876 [details] [diff] [review]
> mozilla-tests config changes
> 
> r+ with one suggestion.  IIRC, we want to keep ESR17 around for a couple of
> updates after TB24 merges in so the comment below should be changed to
> reflect that.
> 
> +# MERGE DAY: Remove comm-esr17 when TB 24 merges in.
> +WIN32_REV3_BRANCHES = ["comm-esr17"]

I just removed the comment because it's not relevant anymore. Those entries will be deleted as a part of esr17 cleanup.
Comment on attachment 800876 [details] [diff] [review]
mozilla-tests config changes

in production
Blocks: 905138
Depends on: 913803
Since releases/comm-release is not used by Thunderbird anymore, it'd be better to get rid of that branch in our automation.

* We still use something like branch = basename(repo) (in buildapi?)
* no need to have exceptions in the automation to match the release config file name
Attachment #802311 - Flags: review?(bhearsum)
Comment on attachment 802311 [details] [diff] [review]
kill comm-release

(In reply to Rail Aliiev [:rail] from comment #13)
> Created attachment 802311 [details] [diff] [review]
> kill comm-release
> 
> Since releases/comm-release is not used by Thunderbird anymore, it'd be
> better to get rid of that branch in our automation.
> 
> * We still use something like branch = basename(repo) (in buildapi?)
> * no need to have exceptions in the automation to match the release config
> file name

This patch seems fine, but what exceptions are you talking about? Are there things somewhere that still want to refer to "comm-release"? If so, why can't they refer to comm-esr24 instead? AFAIK, we can use the comm-esr24 name everywhere and still market the builds as "release".
Attachment #802311 - Flags: review?(bhearsum) → review+
(In reply to Ben Hearsum [:bhearsum] from comment #14)
> This patch seems fine, but what exceptions are you talking about? 

http://mxr.mozilla.org/build/source/tools/lib/python/release/info.py#62 is used by release-runner. If we proced with this patch, we can kill that if when esr17 dies.

> Are there
> things somewhere that still want to refer to "comm-release"? If so, why
> can't they refer to comm-esr24 instead? AFAIK, we can use the comm-esr24
> name everywhere and still market the builds as "release".

I think it's OK to proceed with comm-esr24 and use it everywhere in automation. Maybe I should even rename the patcher configs, but that's not urgent and they don't really use comm-release name, just "release".
Attachment #802342 - Flags: review?(bhearsum)
Attachment #802343 - Flags: review?(bhearsum)
Attachment #802342 - Flags: review?(bhearsum) → review+
Attachment #802343 - Flags: review?(bhearsum) → review+
(In reply to Rail Aliiev [:rail] from comment #15)
> (In reply to Ben Hearsum [:bhearsum] from comment #14)
> > This patch seems fine, but what exceptions are you talking about? 
> 
> http://mxr.mozilla.org/build/source/tools/lib/python/release/info.py#62 is
> used by release-runner. If we proced with this patch, we can kill that if
> when esr17 dies.

Yeah, I think that would be best. The way I see this is that we have something shipping on the release channel, marketed like a capital-R Release, but it happens to be built out of comm-esr24. Given how tightly our automation ties branch name to many things, it's better for us to use the branch name in most places. I'm fine with the state of this now, I'd also be fine with changing the patcher config name to match.
Attached patch graphs (obsolete) — Splinter Review
Attachment #802373 - Flags: review?(jhopkins)
Comment on attachment 802373 [details] [diff] [review]
graphs

You may need to insert these values into 'machines' as well to match Firefox ESR24:

OS_X_10.5.2_comm-esr24
OS_X_10.5.2_comm-esr24_leak_test
WINNT_5.2_comm-esr24
WINNT_6.1_comm-esr24
WINNT_6.1_comm-esr24_leak_test
Attachment #802373 - Flags: review?(jhopkins) → review-
Attached patch graphs [v2]Splinter Review
(In reply to John Hopkins (:jhopkins) from comment #20)
> Comment on attachment 802373 [details] [diff] [review]
> graphs
> 
> You may need to insert these values into 'machines' as well to match Firefox
> ESR24:
> 
> OS_X_10.5.2_comm-esr24
> OS_X_10.5.2_comm-esr24_leak_test

I skipped this platform because it's obsolete.

> WINNT_5.2_comm-esr24
> WINNT_6.1_comm-esr24
> WINNT_6.1_comm-esr24_leak_test

Done, including other branches.
Attachment #802373 - Attachment is obsolete: true
Attachment #802394 - Flags: review?(jhopkins)
Attachment #802394 - Flags: review?(jhopkins) → review+
Depends on: 914709
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
in production
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.