Closed
Bug 1352820
Opened 7 years ago
Closed 6 years ago
[Tracking Bug] Allow SeaMonkey builders to build ESR releases (regular builds and actual release)
Categories
(SeaMonkey :: Release Engineering, enhancement)
SeaMonkey
Release Engineering
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ewong, Assigned: ewong)
References
Details
Attachments
(6 files, 7 obsolete files)
12.77 KB,
patch
|
ewong
:
review+
|
Details | Diff | Splinter Review |
1.51 KB,
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
1.18 KB,
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
7.21 KB,
patch
|
ewong
:
review+
|
Details | Diff | Splinter Review |
2.14 KB,
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
1.50 KB,
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
Since 2.49 will be off ESR, we need to have automation steps to cover this.
Assignee | ||
Comment 1•7 years ago
|
||
there is a difference in this and what TB/Firefox is doing only because I would find it a hassle to change all the necessary code to bump 52 to whatever next esr version is. So setting a variable to control this sounds logical. whether this is right is a different matter. To note: 1) l10n-changesets-comm-esr and release-comm-esr files contain were copied from the comm-release files; but the repos changed. the versions, csets, build#s were changed but since they need to be modified at spin-time, I'm leaving it as is (though I did change the oldbuild # etc in release-comm-esr). 2) in essence, it's kinda like renaming c-a to c-esr and upgrading it to release status.
Comment 2•7 years ago
|
||
Comment on attachment 8865730 [details] [diff] [review] [configs] add comm-esr to builders Sorry ran out of time today for a full review. A few tidbits: > /seamonkey/config.py > +# Set the COMM ESR version > +COMM_ESR_VER = get_gecko_version("comm-esr") > +COMM_ESR = 'comm-esr%d' % COMM_ESR_VER > b/seamonkey/master_common.py > esr = get_gecko_version("comm-esr") Somewhat inconsistent between the two files. > b/seamonkey/l10n-changesets-comm-esr > \ No newline at end of file Intentional? +releaseConfig['version'] = '2.49' I would still like 2.49.1 or let IanN decide :) +releaseConfig['sourceRepoName'] = 'comm-release' # buildbot branch name Can repo name and path differ? > +releaseConfig['inspectorRepoRevision'] = 'DOMI_2_0_16_GECKO_45' > +releaseConfig['chatzillaRepoRevision'] = 'SEA2_42_RELBRANCH' Wrong branches for irc and DOMi. See 2.48 Beta 1. csets need probably changed for release to the latest ones. Also Bug 1353765 has not been check in yet. If it is still delayed it should go into a release branch.
Attachment #8865730 -
Flags: feedback+
Comment 3•7 years ago
|
||
Comment on attachment 8865730 [details] [diff] [review] [configs] add comm-esr to builders ># HG changeset patch ># User Edmund Wong <ewong@pw-wspx.org> ># Parent 73d5b67525d47b0efafb25236075c116d53664e3 >Bug 1352820 - Add ESR releases to builders/releases > >diff --git a/seamonkey/l10n-changesets-comm-esr b/seamonkey/l10n-changesets-comm-esr >new file mode 100644 >--- /dev/null >+++ b/seamonkey/l10n-changesets-comm-esr >@@ -0,0 +1,26 @@ >+be 04a4235e5dfc >+ca 14a74be5358a >+cs 842a16138e8f >+de 874545d8b101 >+en-GB 0657a0ea60e2 >+es-AR 8e72962a04d2 >+es-ES bc3ecb554205 >+fi 31275bfe0742 >+fr 9dfc3b26ba48 >+gl 020204eec53e >+hu 18ed4a160747 >+it 32c5df7e0cc8 >+ja a1ed39e555be >+ja-JP-mac e21435e97313 >+lt 1de1474f4b1c >+nb-NO d595777287ba >+nl a12c44096861 >+pl c89555291e77 Please replace the changeset for Polish (pl) with revision e60eff6e41c3, as unfortunately I've missed a few strings and the installer might end up broken without them: https://hg.mozilla.org/releases/l10n/mozilla-release/pl/rev/e60eff6e41c3
Assignee | ||
Comment 4•7 years ago
|
||
initial patch tried to include the release part. first thing should be done is to include the ESR branches to the builder.
Attachment #8865730 -
Attachment is obsolete: true
Attachment #8865730 -
Flags: review?(frgrahl)
Attachment #8892266 -
Flags: review?(frgrahl)
Assignee | ||
Comment 5•7 years ago
|
||
Attachment #8892267 -
Flags: review?(frgrahl)
Comment 6•7 years ago
|
||
Comment on attachment 8892267 [details] [diff] [review] [configs] Add ESR release builds. Review of attachment 8892267 [details] [diff] [review]: ----------------------------------------------------------------- The used changeset for pl is wrong: it should be e60eff6e41c3 (see comment #3).
Attachment #8892267 -
Flags: review-
Comment 7•7 years ago
|
||
Imho: we shouldn't use the "esr" release-channel but keep using "release" as channel, so all our users do get update-proposals to 2.49.X, as otherwise this will not happen.
Assignee | ||
Updated•7 years ago
|
Severity: normal → blocker
Assignee | ||
Comment 8•7 years ago
|
||
(In reply to Adrian Kalla [:adriank] from comment #6) > Comment on attachment 8892267 [details] [diff] [review] > [configs] Add ESR release builds. > > Review of attachment 8892267 [details] [diff] [review]: > ----------------------------------------------------------------- > > The used changeset for pl is wrong: it should be e60eff6e41c3 (see comment > #3). This bug isn't to release 2.49.1 esr. The csets are just place holders so that when we finally do come across to doing 2.49.1, we will update them as need be.
Comment 9•7 years ago
|
||
(In reply to Edmund Wong (:ewong) from comment #8) > This bug isn't to release 2.49.1 esr. The csets are just place holders so > that when > we finally do come across to doing 2.49.1, we will update them as need be. The problem: at least the pl changeset is not set on the L10n Dashboard, so when we come to choose the right changesets, we will forget this - that's why I think it is better to choose the right one right at the beginning ;)
Comment 10•7 years ago
|
||
I checked the repo and think these should be the final csets. We could probably add them now and forget about them for the 2.49 cycle. They might differ from the current ones because I took the latest available from the 52 cycle. Some only included mail or browser changes. But given the fact that I included one stringset from TB we should take them. The pl e60eff6e41c3 is in a THUNDERBIRD5211_2017050917_RELBRANCH branch. Maybe we should just add our own branch and then merge it or push it as a new patch. cs 392a1ff68cfd Pontoon: Update Czech (cs) localization of Firefox Aurora de fab411f83a79 Bug 1331273 - Missing de localizations for SeaMonkey 2.49. en-GB 3b1783bdb6fd Migrating aurora to beta for Firefox 52 es-AR 313669f76edb Beta is green es-ES 3debdad3d876 Really late-l10n change in Firefox Desktop fr 7e9efb5f39b1 Update Hunspell dictionary to 6.0.2 hu 7ec46b30e96d Pontoon: Update Hungarian (hu) localization of Seamonkey Aurora it 364ba1b94d4d [TrUp] Seamonkey: strings added in identity and on windows installer ja 289cc8d9b658 apply new style of terms: category, editor ja-JP-mac 1dc42d8f8c6b apply new style of terms: category, editor lt 1c563aa726f8 [lt] update from Pootle (thunderbird) nl b3c2ab953068 Verbeterde accesskey voor verwijderen berichtgegevens pl 42ea1da43a3b Migrating aurora to beta for Firefox 52 pl e60eff6e41c3 L10n for Gecko ESR52 branch... THUNDERBIRD5211_2017050917_RELBRANCH pt-PT 5deb6216933d [pt-PT] update from Pootle (seamonkey) ru 216497536532 Update Russian l10n sk 968ee9fbd8ba Migrating aurora to beta for Firefox 52 sv-SE 2d93a3f0c284 Pontoon: Update Swedish (sv-SE) localization of Firefox for Android Aurora zh-CN 02ca4c1400c1 Pontoon: Update Chinese (zh-CN) localization of Firefox Beta zh-TW 4b95fb19a582 Pontoon: Update Chinese (zh-TW) localization of Firefox Beta
Comment 11•7 years ago
|
||
ewong how about we decide Sunday together with IanN if we want to set up separate esr configs or just use release with source from the comm-esr branch? If this is easily possible? I am no longer seeing us doing releases from comm-release in the forseeable future and this might save time with configuring the update servers etc...
Flags: needinfo?(ewong)
Comment 12•7 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #11) > I am no longer seeing us doing releases > from comm-release in the forseeable future and this might save time with > configuring the update servers etc... And even if we would make some releases from c-r, we could setup a new channel for them (like "rc" or something). I think the current "release" user base should stay on 2.49.X until we are certain, that we still can manage to do really stable releases based on c-r (because of the Gecko changes like XUL removal etc.).
Assignee | ||
Comment 13•7 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #11) > ewong how about we decide Sunday together with IanN if we want to set up > separate esr configs or just use release with source from the comm-esr > branch? If this is easily possible? I am no longer seeing us doing releases > from comm-release in the forseeable future and this might save time with > configuring the update servers etc... seeing as I'm the minority here in this thinking, I'm just going to go with the majority and set it up as 'release'. If at the end of the day, we also create an 'rc' c-r release channel, it's going to be the same thing as an 'esr release channel + c-r release channel', just different name. I've asked both Ian and Callek and they feel 'release' is the better way if we're just going to release of ESR.
Flags: needinfo?(ewong)
Assignee | ||
Comment 14•7 years ago
|
||
Attachment #8892266 -
Attachment is obsolete: true
Attachment #8892266 -
Flags: review?(frgrahl)
Attachment #8893250 -
Flags: review?(frgrahl)
Comment 15•7 years ago
|
||
Comment on attachment 8892267 [details] [diff] [review] [configs] Add ESR release builds. Clearing review after irc discussion that we will use release for esr builds.
Attachment #8892267 -
Flags: review?(frgrahl)
Comment 16•7 years ago
|
||
Comment on attachment 8893250 [details] [diff] [review] [configs] Add comm-esr to builders Clearing review after irc discussion that we will use release for esr builds.
Attachment #8893250 -
Flags: review?(frgrahl)
Assignee | ||
Comment 17•7 years ago
|
||
Just to clarify. We are not adding Comm-ESR builders but replacing the comm-release builders with comm-esr? This has nothing to do with the 'release' or 'esr' channel, right?
Comment 18•7 years ago
|
||
Yes, replacing comm-release builders with comm-esr builders and sending their releases to the 'release' channel.
Comment 19•7 years ago
|
||
In case I got it wrong. Should the release builders just use the esr source or be permanently replaced with esr builders? I had in mind that the relase builders just pull from the esr repo and everything else stays the same to save some sycles.
Updated•7 years ago
|
Blocks: SeaMonkey2.49ESR
Assignee | ||
Comment 20•7 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #19) > In case I got it wrong. > > Should the release builders just use the esr source or be permanently > replaced with esr builders? > > I had in mind that the relase builders just pull from the esr repo and > everything else stays the same to save some sycles. Release builders can be pointed to use comm-esr, and thusly we can reuse release-comm-release.py. That said, I'm hoping we can have comm-esr builders as well (at least in the builders page) along side the c-r builders so that one can keep an eye on c-r's status. So the patches were supposed to do the following: 1) add comm-esr builders to the builder page 2) have a new set of release-comm-esr.py/l10n-changesets-comm-esr to the configs 3) the release comm-esr can still made to point to 'release' channel and it still doesn't conflict with what #1 and #2 does.
Assignee | ||
Comment 21•7 years ago
|
||
Please note the following: This patch does the following: 1) Adds the ESR builders to the builder page 2) Adds the necessary files (values in files need to be completed during the config update for the ESR release... this bug isn't about the data. Just the existence of the file.) for ESR release 3) The update channel/release channel is 'release'.
Attachment #8892267 -
Attachment is obsolete: true
Attachment #8893250 -
Attachment is obsolete: true
Attachment #8897902 -
Flags: review?(frgrahl)
Assignee | ||
Comment 22•7 years ago
|
||
These files are needed for the update process. I suspect the updates step will bust as I've never tried creating updates from one tree to another.. i.e. release to esr. It has always been beta-> beta, release-> release. So I'm not sure if our infra 'has' this tree_x -> tree_y. I suspect we'll find out soon enough :)
Attachment #8897904 -
Flags: review?(frgrahl)
Comment 23•7 years ago
|
||
Comment on attachment 8897904 [details] [diff] [review] [tools] files required for ESR patcher configs/verification files. r+ but these are 1:1 copies of the release files so I would just do a hg copy e.g. diff --git a/release/updates/patcher-configs/mozRelease-seamonkey-branch-patcher2.cfg b/release/updates/patcher-configs/mozEsr-seamonkey-branch-patcher2.cfg copy from release/updates/patcher-configs/mozRelease-seamonkey-branch-patcher2.cfg copy to release/updates/patcher-configs/mozEsr-seamonkey-branch-patcher2.cfg
Attachment #8897904 -
Flags: review?(frgrahl) → review+
Comment 24•7 years ago
|
||
Comment on attachment 8897902 [details] [diff] [review] [configs] add ESR builders seamonkey\config.py > # staging/production-dependent settings - all is production for us > BRANCHES['comm-esr']['tinderbox_tree'] = 'SeaMonkey-ESR%d' % COMM_ESR_VER > BRANCHES['comm-esr']['packaged_unittest_tinderbox_tree'] = 'SeaMonkey-ESR%d' % Shouldn't SeaMonkey-ESR%d be better SeaMonkey-esr%d or ...-Esr%d seamonkey\l10n\all-locales.comm-esr Needs to be aligned with the suite locales. Some languages were removed starting with 2.48
Attachment #8897902 -
Flags: review?(frgrahl) → review+
Assignee | ||
Comment 25•7 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #24) > Comment on attachment 8897902 [details] [diff] [review] > [configs] add ESR builders > > seamonkey\config.py > > > # staging/production-dependent settings - all is production for us > > BRANCHES['comm-esr']['tinderbox_tree'] = 'SeaMonkey-ESR%d' % COMM_ESR_VER > > BRANCHES['comm-esr']['packaged_unittest_tinderbox_tree'] = 'SeaMonkey-ESR%d' % > > Shouldn't SeaMonkey-ESR%d be better SeaMonkey-esr%d or ...-Esr%d ESR is because ESR isn't even a word, whereas Beta and Release are. That said, it really matters not. If you prefer Esr, I'll set it to that. > > seamonkey\l10n\all-locales.comm-esr > > Needs to be aligned with the suite locales. Some languages were removed > starting with 2.48 Gotcha.
Assignee | ||
Comment 26•7 years ago
|
||
Attachment #8897902 -
Attachment is obsolete: true
Attachment #8898555 -
Flags: review+
Assignee | ||
Comment 27•7 years ago
|
||
Attachment #8897904 -
Attachment is obsolete: true
Attachment #8898556 -
Flags: review?(frgrahl)
Comment 28•7 years ago
|
||
Comment on attachment 8898556 [details] [diff] [review] [tools] add patcher-config/verification updates cfg for ESR builds Great
Attachment #8898556 -
Flags: review?(frgrahl) → review+
Assignee | ||
Comment 29•7 years ago
|
||
Attachment #8902135 -
Flags: review?(frgrahl)
Assignee | ||
Comment 30•7 years ago
|
||
Attachment #8902136 -
Flags: review?(frgrahl)
Comment 31•7 years ago
|
||
Comment on attachment 8902135 [details] [diff] [review] [config] use THUNDERBIRD_52_VERBRANCH for ESR only. [checked-in] Looks good. Is this needed for automation? I thought we set the branch otherwise like in the buildbot-configs seamonkey\release-comm-release.py? > releaseConfig['mozillaRelbranchOverride'] = 'SEA_COMM510_20170330_RELBRANCH' > # put Gecko relbranch here that we base upon
Attachment #8902135 -
Flags: review?(frgrahl) → review+
Updated•7 years ago
|
Attachment #8902136 -
Flags: review?(frgrahl) → review+
Assignee | ||
Comment 32•7 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #31) > Comment on attachment 8902135 [details] [diff] [review] > [config] use THUNDERBIRD_52_VERBRANCH for ESR only. > > Looks good. Is this needed for automation? I thought we set the branch > otherwise like in the buildbot-configs seamonkey\release-comm-release.py? > > > releaseConfig['mozillaRelbranchOverride'] = 'SEA_COMM510_20170330_RELBRANCH' > > # put Gecko relbranch here that we base upon No, this is for release automation. That patch was for the regular triggered ESR builds, which is why I asked in bug 1346939 whether those two patches can be pushed to default. Since they can't, I'll have to use this way of separating c-c,c-b and c-r's default pull of m-* to c-esr's pull of m-esr.
Assignee | ||
Comment 33•7 years ago
|
||
Attachment #8902136 -
Attachment is obsolete: true
Attachment #8907453 -
Flags: review+
Assignee | ||
Updated•7 years ago
|
Attachment #8902135 -
Attachment description: [config] use THUNDERBIRD_52_VERBRANCH for ESR only. → [config] use THUNDERBIRD_52_VERBRANCH for ESR only. [checked-in]
Assignee | ||
Comment 34•7 years ago
|
||
Comment on attachment 8907453 [details] [diff] [review] [custom] Ensure relbranch is used if esr. (bitrot-fix) [checked-in] was bitrotted and fixed a spelling (s/mozillaRelbranch/mozillaRelBranch/).
Attachment #8907453 -
Attachment description: [custom] Ensure relbranch is used if esr. (bitrot-fix) → [custom] Ensure relbranch is used if esr. (bitrot-fix) [checked-in]
Assignee | ||
Comment 35•7 years ago
|
||
Attachment #8907471 -
Flags: review?(frgrahl)
Assignee | ||
Comment 36•7 years ago
|
||
Comment on attachment 8907471 [details] [diff] [review] [custom] relbranch update should be done after checkout. gonna do a post-land-review
Comment 37•7 years ago
|
||
Comment on attachment 8907471 [details] [diff] [review] [custom] relbranch update should be done after checkout. I assume this now always updates to the current head if not the default branch because > command=['hg', 'up', '-C', '-r', self.buildRevision],. is executed earlier. Fine with me until we find a case where it doesn't work. Just for clarification :)
Attachment #8907471 -
Flags: review?(frgrahl) → review+
Assignee | ||
Comment 38•7 years ago
|
||
instead of creating relbranches for the locales to ensure they are en-par with those locales that had relbranches created for them, just basically allow the additional mention of the relbranch after the revision in the l10n-changesets-comm-* file.
Attachment #8909205 -
Flags: review?(frgrahl)
Comment 39•7 years ago
|
||
Comment on attachment 8909205 [details] [diff] [review] [custom] allow the specification of relbranch in l10n-changesets-comm-* Looks good and will make IanN happy :)
Attachment #8909205 -
Flags: review?(frgrahl) → review+
Assignee | ||
Comment 40•7 years ago
|
||
Pushed to buildbotcustom: https://hg.mozilla.org/build/buildbotcustom/rev/0bb22a3e6b77
Assignee | ||
Comment 42•6 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #41) > are we done here? I would say so.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(ewong)
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•