Unlike previous ESR branches we shouldn't enable nightly builds or use "esrpre" style versions. See bugs 1135024 and 1133250 for background on those things.

ESR31 was created in bug 1012647 as a reference

It would be also great to revise the docs at https://wiki.mozilla.org/ReleaseEngineering/How_To/Create_new_ESR_branch

There a chance that we'll need to enable win64 on esr38

checkconfig passes

Comment on attachment 8598867 [details] [diff] [review] esr38-tools.diff Review of attachment 8598867 [details] [diff] [review]: ----------------------------------------------------------------- Can we really drop comm-esr31 ? Is there going to be no overlap ?

Comment on attachment 8598868 [details] [diff] [review] esr38-buildbot-configs-2.diff Review of attachment 8598868 [details] [diff] [review]: ----------------------------------------------------------------- Similar question about dropping comm-esr31 without any overlap with esr38. ::: mozilla/release-firefox-mozilla-esr38.py.template @@ +36,5 @@ > releaseConfig['appVersion'] = '{{ appVersion }}' > releaseConfig['milestone'] = releaseConfig['appVersion'] > releaseConfig['buildNumber'] = {{ buildNumber }} > releaseConfig['baseTag'] = '{{ baseTag }}' > +releaseConfig['partialUpdates'] = {} Please add a TODO so that we put the template back in for the first updates. @@ +114,5 @@ > releaseConfig['releaseChannel'] = 'esr' > releaseConfig['updateChannels'] = { > "esr": { > "versionRegex": r"^.*$", > "ruleId": 34, The three ruleIDs will need to be adjusted to whatever we end up for the esr38 specific rules in Balrog. Later ? ::: mozilla/staging_release-firefox-mozilla-esr38.py @@ +32,3 @@ > releaseConfig['partialUpdates'] = { > '31.3.0esr': { > 'appVersion': '31.3.0', Might be worth emptying this out too.

(In reply to Nick Thomas [:nthomas] from comment #6) > Comment on attachment 8598867 [details] [diff] [review] > esr38-tools.diff > > Review of attachment 8598867 [details] [diff] [review]: > ----------------------------------------------------------------- > > Can we really drop comm-esr31 ? Is there going to be no overlap ? This is what we did last time. See http://hg.mozilla.org/build/buildbot-configs/rev/9f0b1c086769 (In reply to Nick Thomas [:nthomas] from comment #7) > Comment on attachment 8598868 [details] [diff] [review] > esr38-buildbot-configs-2.diff > > Review of attachment 8598868 [details] [diff] [review]: > ----------------------------------------------------------------- > > Similar question about dropping comm-esr31 without any overlap with esr38. > > ::: mozilla/release-firefox-mozilla-esr38.py.template > @@ +36,5 @@ > > releaseConfig['appVersion'] = '{{ appVersion }}' > > releaseConfig['milestone'] = releaseConfig['appVersion'] > > releaseConfig['buildNumber'] = {{ buildNumber }} > > releaseConfig['baseTag'] = '{{ baseTag }}' > > +releaseConfig['partialUpdates'] = {} > > Please add a TODO so that we put the template back in for the first updates. Sure. > @@ +114,5 @@ > > releaseConfig['releaseChannel'] = 'esr' > > releaseConfig['updateChannels'] = { > > "esr": { > > "versionRegex": r"^.*$", > > "ruleId": 34, > > The three ruleIDs will need to be adjusted to whatever we end up for the > esr38 specific rules in Balrog. Later ? Good catch. I think this is what we need to do here: 1) create a new set of rules for esr with version > 38.0 2) whenever we ready to ship esr38 to other esr versions, drop the version restriction (or set to 31, if 24 is not ready) and delete old rules. Something like https://aus4-admin-dev.allizom.org/rules#esr%2038 Does it make sense? > ::: mozilla/staging_release-firefox-mozilla-esr38.py > @@ +32,3 @@ > > releaseConfig['partialUpdates'] = { > > '31.3.0esr': { > > 'appVersion': '31.3.0', > > Might be worth emptying this out too. I also found that the staging channel names are wrong.

Additionally I may need to drop win64 support.

I don't know the full implications of dropping comm-esr31 in this bug, but there will certainly be significant overlap of comm-esr31 and comm-esr38. We'll be doing Thunderbird releases off of comm-esr31 as long as there is a viable mozilla-esr31.

(In reply to Kent James (:rkent) from comment #10) > I don't know the full implications of dropping comm-esr31 in this bug, but > there will certainly be significant overlap of comm-esr31 and comm-esr38. > We'll be doing Thunderbird releases off of comm-esr31 as long as there is a > viable mozilla-esr31. Thunderbird release automation doesn't support multiple lines for the same channel (release). comm-esr38 is just a repo name, not a separate channel. In other words the current workflow doesn't support overlaps. We did the same in bug 1015942 when switched from esr24 to esr31. It would be great if we continue following the same workflow for this version as well. Otherwise it would be hard to be ready for next week's releases - we have a bunch of them. :/

As I understand it, in Thunderbird 31 there were initially significant regressions so that updates of existing Thunderbird 24 users was delayed until 31.2 or 31.3 I'm not quite sure how that looks from a channel perspective. How does Firefox do this? Will you able to do a security update of a user to a new 31.x release after 38.0 is released? I'm not advocating making a change to whatever has been done in the past though.

(In reply to Kent James (:rkent) from comment #12) > As I understand it, in Thunderbird 31 there were initially significant > regressions so that updates of existing Thunderbird 24 users was delayed > until 31.2 or 31.3 I'm not quite sure how that looks from a channel > perspective. We didn't push the updates to the release channel in that case. > How does Firefox do this? What we do in Firefox is a PITA and causes a lot of pain during initial setup and for all builds that overlap. > Will you able to do a security update of a user to > a new 31.x release after 38.0 is released? Not if 38.0 is not pushed and there is a security release. > I'm not advocating making a change to whatever has been done in the past > though. I would really prefer to keep the same workflow we had last time to avoid unpredicted issues. Releng is really busy these days with all these "urgent" projects, especially FTP migration. :(

* added new rule IDs that match version > 38.0 * dropped win64 support * addressed the comments

Dropped win64

Comment on attachment 8599488 [details] [diff] [review] esr38-buildbot-configs-3.diff Ignore these for now, I'm going to split FF and TB.

Comment on attachment 8599488 [details] [diff] [review] esr38-buildbot-configs-3.diff Review of attachment 8599488 [details] [diff] [review]: ----------------------------------------------------------------- r+ with a few nits - release-thunderbird-comm-esr38.py.template and similar need the partials blanked out like Firefox has; and also updated balrog ruleIds. Also, the version conditions in the Balrog rules will need to be '>=38.0' instead of '>38.0'.

I split the patches so we can switch to comm-esr38 whenever we are ready. They pass checkconfig on dev-master.

:rkent, the current plan is to leave TB release on esr31, regardless of FF channel. Whenever you are ready we can switch to comm-esr38. Would this help?

(In reply to Nick Thomas [:nthomas] from comment #17) > Comment on attachment 8599488 [details] [diff] [review] > esr38-buildbot-configs-3.diff > > Review of attachment 8599488 [details] [diff] [review]: > ----------------------------------------------------------------- > > r+ with a few nits - release-thunderbird-comm-esr38.py.template and similar > need the partials blanked out like Firefox has; and also updated balrog > ruleIds. Thunderbird doesn't have overlaps like FF ESR, this is why those entries are valid. > > Also, the version conditions in the Balrog rules will need to be '>=38.0' > instead of '>38.0'. Right... Fixing

Comment on attachment 8599622 [details] [diff] [review] tools-esr38-no-tb.diff Review of attachment 8599622 [details] [diff] [review]: ----------------------------------------------------------------- ::: lib/python/mozilla_buildtools/test/test_release_info.py @@ +32,5 @@ > self.assertEquals('release-firefox-mozilla-release.py', got) > > def testThunderbird(self): > + got = getReleaseConfigName('thunderbird', 'comm-esr38') > + self.assertEquals('release-thunderbird-comm-esr38.py', got) Technically this belongs in the other patch ;-)

Comment on attachment 8599619 [details] [diff] [review] buildbot-configs-esr38-no-thunderbird.diff https://hg.mozilla.org/build/buildbot-configs/rev/9eb93630dfc1

Comment on attachment 8599622 [details] [diff] [review] tools-esr38-no-tb.diff https://hg.mozilla.org/build/tools/rev/5bce3e748017

In production: https://hg.mozilla.org/build/buildbot-configs/rev/9eb93630dfc1

staging treeherder got it: https://treeherder.allizom.org/#/jobs?repo=mozilla-esr38

Per IRC, we want to have some overlap for comm-esr31 and comm-esr38. It didn't work from the first attempt - hitting builder limits for tst-linux64 :/

* add comm-esr38 * rename patcher and update verify configs from mozRelease to mozEsr31 * add empty esr38 patcher and update verify configs

* Disable fig, which had no pushes since November to pass the builder limit errors * add comm-esr38 * update patcher and update verify config names according to the tools patch * update latest symlink names * add new rules to handle future esr38 updates (until 31 EOL) * disable updates/partials for esr38 * disable comm-esr31 nightlies * release*.py files updated just to pass checkconfig/reconfig, they'll be regenerated later

Comment on attachment 8602131 [details] [diff] [review] comm-esr31+38-buildbot-configs-2.diff Review of attachment 8602131 [details] [diff] [review]: ----------------------------------------------------------------- Fig is booked by mreavy@mozilla.com. Can you please verify with her that she doesn't need it anymore before landing this? ::: mozilla/release-thunderbird-comm-esr31.py @@ +127,5 @@ > releaseConfig['updateChannels'] = { > "release": { > "versionRegex": r"^.*$", > "ruleId": 35, > + "patcherConfig": "mozEsr31-thunderbird-branch-patcher2.cfg", I'm not sure this change makes sense. Whichever one of the branches will be shipping updates to the "release" channel should use mozRelease configs, shouldn't it? It makes a lot more sense to me to have update configs correspond to the channel they're working with rather than the branch they happen to built from...

I can rename the files back, but encoding the branch name into the file instead of the channel has some pluses. Both update lines submit to the same channel, even though the rule IDs are different. At some point, when we decide to ship 38 to all users, we'll just need to adjust the Balrog rules, without touching (renaming) the patcher/verify configs.

(In reply to Rail Aliiev [:rail] from comment #33) > I can rename the files back, but encoding the branch name into the file > instead of the channel has some pluses. Both update lines submit to the same > channel, even though the rule IDs are different. At some point, when we > decide to ship 38 to all users, we'll just need to adjust the Balrog rules, > without touching (renaming) the patcher/verify configs. If you feel this strongly I'm not going to object, but I still think it's a bit confusing to use branch names instead of channels in patcher/update verify config filenames. When I see "mozEsr38" I think that the files are only relevant to esr38 releases - not _all_ esrs.

Comment on attachment 8602129 [details] [diff] [review] comm-esr31+38-tools.diff https://hg.mozilla.org/build/tools/rev/9a3ac70c978a

Comment on attachment 8602131 [details] [diff] [review] comm-esr31+38-buildbot-configs-2.diff https://hg.mozilla.org/build/buildbot-configs/rev/3c4fe0bde1d7

In production: https://hg.mozilla.org/build/buildbot-configs/rev/9eb93630dfc1

In production: https://hg.mozilla.org/build/buildbot-configs/rev/3c4fe0bde1d7

Brings over the filename change for the patcher config. This is what manages the symlink at /pub/mozilla.org/thunderbird/nightly/latest-candidate-comm-release.

Comment on attachment 8603037 [details] [diff] [review] [svn productdelivery] Fix up cron Committed revision 104217.

Enable updates for TB 38, patcher config patch incoming

cp mozEsr31-thunderbird-branch-patcher2.cfg mozEsr38-thunderbird-branch-patcher2.cfg

Comment on attachment 8604879 [details] [diff] [review] tb38-tools.diff It's possible there will be a problem bumping this, lets solve that later.

Comment on attachment 8604879 [details] [diff] [review] tb38-tools.diff https://hg.mozilla.org/build/tools/rev/51a262af62c3

Comment on attachment 8604877 [details] [diff] [review] tb38-buildbot-configs.diff https://hg.mozilla.org/build/buildbot-configs/rev/978825343150

it's similar to http://hg.mozilla.org/build/tools/rev/f1ec46bab22f

Comment on attachment 8605608 [details] [diff] [review] tools-add-38.0esr-patcher-config.diff >diff --git a/release/patcher-configs/mozEsr38-branch-patcher2.cfg b/release/patcher-configs/mozEsr38-branch-patcher2.cfg >+ details https://www.mozilla.com/%locale%/firefox/38.0/releasenotes/ >+ </partials> No opening <partials>, please add one. >+ <release> >+ <38.0esr> >+ checksumsurl http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/24.0esr-candidates/build1/%platform%/%locale%/firefox-24.0esr.checksums >+ completemarurl http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/24.0esr-candidates/build1/update/%platform%/%locale%/firefox-24.0esr.complete.mar s/24\.0/38.0/g >+ locales ach af an ar as ast az be bg bn-BD bn-IN br bs ca cs cy da de dsb el en-GB en-US en-ZA eo es-AR es-CL es-ES es-MX et eu fa ff fi fr fy-NL ga-IE gd gl gu-IN he hi-IN hr hsb hu hy-AM id is it ja linux win32 ja-JP-mac osx kk km kn ko lij lt lv mai mk ml mr ms nb-NO nl nn-NO or pa-IN pl pt-BR pt-PT rm ro ru si sk sl son sq sr sv-SE ta te th tr uk uz vi xh zh-CN zh-TW There's some platform goo in there, try this ach af an ar as ast az be bg bn-BD bn-IN br bs ca cs cy da de dsb el en-GB en-US en-ZA eo es-AR es-CL es-ES es-MX et eu fa ff fi fr fy-NL ga-IE gd gl gu-IN he hi-IN hr hsb hu hy-AM id is it ja ja-JP-mac kk km kn ko lij lt lv mai mk ml mr ms nb-NO nl nn-NO or pa-IN pl pt-BR pt-PT rm ro ru si sk sl son sq sr sv-SE ta te th tr uk uz vi xh zh-CN zh-TW r+ with those fixed up.

Comment on attachment 8605608 [details] [diff] [review] tools-add-38.0esr-patcher-config.diff remote: https://hg.mozilla.org/build/tools/rev/651f86737204 remote: https://hg.mozilla.org/build/tools/rev/066b81eef190 Tagged as well

Comment on attachment 8605812 [details] [diff] [review] configs-enable-esr38-updates.diff https://hg.mozilla.org/build/buildbot-configs/rev/82d98710a67d

In production: https://hg.mozilla.org/build/buildbot-configs/rev/978825343150

In production: https://hg.mozilla.org/build/buildbot-configs/rev/82d98710a67d