The default bug view has changed. See this FAQ.

stop precreating relbranches

RESOLVED FIXED

Status

Release Engineering
Release Automation
P3
normal
RESOLVED FIXED
4 years ago
10 months ago

People

(Reporter: bhearsum, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
As far as Nick and I can tell there is no need for relbranches anymore. We don't land changes on mozilla-release that we aren't going to ship, and on mozilla-beta we always ship tip of default. If we do need to we can create them after the fact. We will have to move version buwps to default to do this.

#summitideas.
(Reporter)

Comment 1

4 years ago
Just had a look, this is easy to do. Need to adjust this logic to remove relbranches:
https://mxr.mozilla.org/build-central/source/tools/scripts/release/tag-release.py#65

And then remove a bunch of relbranch references from other code:
https://mxr.mozilla.org/build-central/source/buildbotcustom/process/release.py#357
https://mxr.mozilla.org/build-central/source/buildbotcustom/test/test_hgpoller.py
https://mxr.mozilla.org/build-central/source/buildbotcustom/misc.py
https://mxr.mozilla.org/build-central/source/buildbotcustom/misc.py
https://mxr.mozilla.org/build-central/source/tools/lib/python/mozilla_buildtools/test/test_util_hg.py
https://mxr.mozilla.org/build-central/source/tools/lib/python/mozilla_buildtools/test/test_release_l10n.py
https://mxr.mozilla.org/build-central/source/tools/lib/python/mozilla_buildtools/test/test_release_l10n.py
https://mxr.mozilla.org/build-central/source/tools/lib/python/release/info.py
https://mxr.mozilla.org/build-central/source/tools/lib/python/release/l10n.py
Priority: -- → P3
We had a counter example with Thunderbird 25.0b1 today, which used a relbranch to have a TB specific change (http://hg.mozilla.org/releases/mozilla-beta/rev/584dbfb67083). So perhaps we need to retain support even if we don't use it by default, sigh.
OS: Android → All
(Reporter)

Comment 3

4 years ago
(In reply to Nick Thomas [:nthomas] from comment #2)
> We had a counter example with Thunderbird 25.0b1 today, which used a
> relbranch to have a TB specific change
> (http://hg.mozilla.org/releases/mozilla-beta/rev/584dbfb67083). So perhaps
> we need to retain support even if we don't use it by default, sigh.

In this example couldn't we have updated to that changes' parent, created the branch by hand, landed the change, and then passed the new revision to ship it? If we fix this bug and do that I think that will work the same as now, the only difference being the location of the tag commits.
I presume Mark did most of what you suggest to create that changeset, and it sounds like what you propose will work. 

Another scenario worth noting - doing a x.0.1 build on default must be done from a tip revision, otherwise version bumping would create a new head. That seems fine, you can always create a relbranch if you don't want tip for some odd reason, but maybe release-sanity should check for 'tipness'.
(Reporter)

Comment 5

4 years ago
(In reply to Nick Thomas [:nthomas] from comment #4)
> I presume Mark did most of what you suggest to create that changeset, and it
> sounds like what you propose will work. 
> 
> Another scenario worth noting - doing a x.0.1 build on default must be done
> from a tip revision, otherwise version bumping would create a new head. That
> seems fine, you can always create a relbranch if you don't want tip for some
> odd reason, but maybe release-sanity should check for 'tipness'.

This could be problematic for the automation if it gets fed a non-tip revision...I think the single head hook on the server would reject the push.

Were you alluding to changing the automation to only create a relbranch if one has been specified on ship it in comment #2? Maybe that *is* a good first step in case there's other use cases we're not remembering right now...
(In reply to Ben Hearsum [:bhearsum] from comment #5)
> Were you alluding to changing the automation to only create a relbranch if
> one has been specified on ship it in comment #2? Maybe that *is* a good
> first step in case there's other use cases we're not remembering right now...
Flags: needinfo?(nthomas)
I'm not sure what I meant after all this time. Tagging the gecko repo usually goes like this (from memory, wcpgw):
* update to the revision from ship-it
* create a relbranch
* bump one or more version files, commit   (1)
* create tags on (1)
* update to default
* bump again
* commit (2)

The commit at (1) will always produce a changeset, because of the way of hg handles branches (it somehow lumps in the branch creation). Generally they are empty checkins unless we're doing a x.0.y release (there's nothing to do on beta because the version doesn't change, and for b1 because the version gets bumped by the merge script; an x.0 release has the same version as beta). 

The 2nd bump is usually a no-op and doesn't result in a changeset at the commit, except for x.0.y on release.

Seems to me that we can change the tagging script to create a relbranch if ship-it rev isn't the tip of default, otherwise not bother. Still slighty sucky for multiple releases in flight, in that the not-first release will see tip != rev and create an unnecessary relbranch. There may be some more complicated approach based on checking if the bump actually does anything, and rev != tip of default, before creating the relbranch.
Flags: needinfo?(nthomas)
The recent chemspill (Firefox 32.0.3) is another example of why relbranches are still needed. ESR31 picked up additional changes that shipped with minimal testing because we didn't build off of a relbranch. This doesn't mean that the relbranch needs to be created up front (we can create them on demand) but does mean that there is a use.

Note that for Firefox 31.1 we will likely be landing changes on mozilla-release that will not be able to ship if a chemspill is required between the time that the changes land and the time when 33.1 ships.
(Reporter)

Comment 9

3 years ago
(In reply to Lawrence Mandel [:lmandel] from comment #8)
> The recent chemspill (Firefox 32.0.3) is another example of why relbranches
> are still needed. ESR31 picked up additional changes that shipped with
> minimal testing because we didn't build off of a relbranch. This doesn't
> mean that the relbranch needs to be created up front (we can create them on
> demand) but does mean that there is a use.
> 
> Note that for Firefox 31.1 we will likely be landing changes on
> mozilla-release that will not be able to ship if a chemspill is required
> between the time that the changes land and the time when 33.1 ships.

It's worth noting that even if we don't precreate them, we can still create them after the fact if we have a chemspill. So this bug should really be "stop precreating relbranches".
Summary: kill relbranches → stop precreating relbranches
You don't *need* branches. Mercurial supports anonymous, unnamed heads. This is how try currently works, for example. Now, this may make tracking difficult, which is why there are bookmarks and branches (to help give symbolic names for humans to reference).

I just wanted to throw that out there in case it makes someone dream up an alternate solution.

Also, I dislike relbranches so much that I'm willing to implement any custom Mercurial functionality to track releases from the Mercurial server if Mercurial's built-in primitives aren't good enough. See http://gregoryszorc.com/blog/2014/01/17/things-mozilla-could-do-with-mercurial/ for some potential ideas. I imagine release "branch" tracking could be a custom label namespace similar to bookmarks. I'd be happy to talk with someone about it though.

Also, the Mercurial project is always keen to learn about scenarios where Mercurial doesn't work. I'd say this is one of them. Type of your requirements in a concise form so I can float them to the Mercurial project and see what others have to say. The subject of "fixing labels" has come up before and this could very well make it into Mercurial core someday.
Kent does this potentially impact us?
Flags: needinfo?(rkent)

Comment 12

10 months ago
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #11)
> Kent does this potentially impact us?

I can't think of any reason that we would want them routinely created as they are now.

We have started to use release branches on mozilla-beta so that we can land a few additional patches that Thunderbird needs, and that way we don't have to pressure mozilla-beta release drivers to take our patches. But those releases branches are created manually by me, so do not need to be created by automation.

Agreeing with comment 10, this could be done without branches (relying on tags to track actual shipped revisions) as long as the automation does not reject multiple named heads.

We do need a branch on mozilla-esr45 (THUNDERBIRD_45_VERBRANCH) but again this is managed entirely manually by me, and it is a version branch (persisting over the life of esr45) rather than a release branch (used for a single release).
Flags: needinfo?(rkent)
relbranches are dead in release promotion!
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.