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)

enhancement
Not set
blocker

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.
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.
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #8865730 - Flags: review?(frgrahl)
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 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
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)
Attachment #8892267 - Flags: review?(frgrahl)
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-
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.
Severity: normal → blocker
(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.
(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 ;)
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
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)
(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.).
(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)
Attachment #8892266 - Attachment is obsolete: true
Attachment #8892266 - Flags: review?(frgrahl)
Attachment #8893250 - Flags: review?(frgrahl)
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 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)
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?
Yes, replacing comm-release builders with comm-esr builders and sending their releases to the 'release' channel.
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.
(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.
Attached patch [configs] add ESR builders (obsolete) — Splinter Review
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)
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 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 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+
(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.
Attachment #8897902 - Attachment is obsolete: true
Attachment #8898555 - Flags: review+
Attachment #8897904 - Attachment is obsolete: true
Attachment #8898556 - Flags: review?(frgrahl)
Comment on attachment 8898556 [details] [diff] [review]
[tools] add patcher-config/verification updates cfg for ESR builds

Great
Attachment #8898556 - Flags: review?(frgrahl) → review+
Attachment #8902136 - Flags: review?(frgrahl)
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+
Attachment #8902136 - Flags: review?(frgrahl) → review+
(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.
Attachment #8902135 - Attachment description: [config] use THUNDERBIRD_52_VERBRANCH for ESR only. → [config] use THUNDERBIRD_52_VERBRANCH for ESR only. [checked-in]
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]
Comment on attachment 8907471 [details] [diff] [review]
[custom] relbranch update should be done after checkout.

gonna do a post-land-review
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+
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 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+
are we done here?
Flags: needinfo?(ewong)
(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.