1342884 - Add http://hg.mozilla.org/releases/mozilla-esr52/ branch to gecko-dev

Status: RESOLVED FIXED

(Developer Services :: General, task)

Description

[Georg Koppen]

We'd like to have mozilla-esr52 as a branch in gecko-dev to be able to use that one in our upcoming Tor Browser switch to ESR52.

Comment 1

[Kendall Libby [:fubar] (he/him)]

:dhouse, another vcs-sync bug for ya! should just be: https://wiki.mozilla.org/ReleaseEngineering/How_To/VCSSync#How_to_add_a_repo_to_gecko-dev

Comment 2

[:dhouse]

Looking at esr45 as an example, from bug 1250618.

Comment 3

[:dhouse]

Attachment: bug1342884_add-esr52-to-gecko-dev.patch

Adding clone of https://hg.mozilla.org/releases/mozilla-esr52
to gecko-dev in mozharness/configs/vcs-sync

Comment 4

[Hal Wine [:hwine] use NI!]

Comment on attachment 8844314 [details] [diff] [review]
bug1342884_add-esr52-to-gecko-dev.patch

Review of attachment 8844314 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm -- I _thought_ we had updating gecko-dev as part of the process of creating the hg branch. If not, it should be added - we'll always want to update gecko-dev when we create a new branch to release from on hg.m.o

Comment 5

[Kendall Libby [:fubar] (he/him)]

(In reply to Hal Wine [:hwine] (use NI) from comment #4)
> I _thought_ we had updating gecko-dev as part of the process of
> creating the hg branch. If not, it should be added - we'll always want to
> update gecko-dev when we create a new branch to release from on hg.m.o

never been the case, afaik. from our side, we just get the request to clone to esrXX (bug 1337066) and add to dxr (bug 1341330). rarely, we get other related requests (bug 1339074).

can the two of you work out what documentation needs to be changed, and change it?

Comment 6

[:dhouse]

:hwine Is this the page that needs a step added to "create a bug for vcs-sync of the new esr hg branch". https://wiki.mozilla.org/Releases/Set_Up_ESR_Branch

I added the steps for the bugs that :fubar listed. Please feel free to edit or revoke my changes!

Comment 7

[:dhouse]

Applied and pushed to default:
remote:   https://hg.mozilla.org/build/mozharness/rev/98b09bd2c7235a2172897ed0a212d890eebb5407

Comment 8

[:dhouse]

Travis passed.
Pushed to production:
remote:   https://hg.mozilla.org/build/mozharness/rev/8775f033bebceb3a3ecc1879bc6d6de6dd5ccc5f

Comment 9

[:dhouse]

Georg, I'll close this bug. If you see any issues with the mozilla-esr52 branch in gecko-dev, please re-open this bug.

The esr52 branch correctly appears on github now, https://github.com/mozilla/gecko-dev/commits/esr52, and it shows commits from today.

Comment 10

[Hal Wine [:hwine] use NI!]

(In reply to Kendall Libby [:fubar] from comment #5)
> (In reply to Hal Wine [:hwine] (use NI) from comment #4)
> > I _thought_ we had updating gecko-dev as part of the process of
> > creating the hg branch. If not, it should be added - we'll always want to
> > update gecko-dev when we create a new branch to release from on hg.m.o
> 
> never been the case, afaik. from our side, we just get the request to clone
> to esrXX (bug 1337066) and add to dxr (bug 1341330). rarely, we get other
> related requests (bug 1339074).

See https://mana.mozilla.org/wiki/display/DEVSERVICES/Mercurial+-+Common+Repository+Operations#Mercurial-CommonRepositoryOperations-NewGeckoRepository which covers all the cases involved in this bug/case

> can the two of you work out what documentation needs to be changed, and
> change it?

In my opinion, all of the steps in mana rightfully belong to dev services (i.e. they're in the right place). They all have to do with making the new repo available. (E.g. I had no idea about the need for at least 2 of the bugs related to firefoxtrees and other extensions.)

(In reply to Dave House [:dhouse] from comment #6)
> :hwine Is this the page that needs a step added to "create a bug for
> vcs-sync of the new esr hg branch".
> https://wiki.mozilla.org/Releases/Set_Up_ESR_Branch
> 
> I added the steps for the bugs that :fubar listed. Please feel free to edit
> or revoke my changes!

Wasn't it Harlan Ellison who wrote that horror story "I have no librarian, and I must document!"

dhouse++ for getting the docs in somewhere
mozilla-- for not having curators for documentation (there's a reason most large tech companies have librarians on staff)

Here's some crumbs for later folks heading down this rabbit hole (you may want to pack refreshments for the trip):
 a) There used to be confusion w.r.t. ESR between RelMan (Release in the wiki) and RelEng (ReleaseEngineering in the wiki)
 b) The page https://wiki.mozilla.org/Releases/Set_Up_ESR_Branch dates from that era, and has not been updated in ages.
 c) ProTip for releng docs - whenever it fits, we try to have "how to" in the page title name, so a search (google, not inside wiki) like |site:wiki.mozilla.org "how to" esr| turned up a more current candidate:
     https://wiki.mozilla.org/ReleaseEngineering/How_To/Create_new_ESR_branch
 d) Which, of course, points to somewhere else as the latest authority:
     https://github.com/mozilla/releasewarrior/blob/master/how-tos/new-esr-branch-setup.md

In reviewing the list at (d), there is some overlap with the mana page steps. While redundancy is evil, so are steps falling through the cracks on a once-every-7-release-cycles task, so I'm inclined to leave those alone and risk a dup'd bug.

Net action: I reverted (a) as all those changes are already documented in mana and (d), which are both more recent.