664654 - release_bft.py tries to checkout unknown branch "mozilla-release" for Firefox 5.0build1

Status: VERIFIED FIXED

(Mozilla QA Graveyard :: Mozmill Automation, defect)

Description

[u279076]

Attempting to run the release_bft.py script on the release candidate builds for Firefox 5.0 results in a "unknown revision 'mozilla-release'" error. The following is the console output from the WinXP VM (but this happens in all VMs and host):

$ ./release_bft.py 5.0 winxp
*** Cloning repository to 'c:\docume~1\mozilla\locals~1\temp\tmphdknnt.mozmill-tests'
requesting all changes
adding changesets
adding manifests
adding file changes
added 1324 changesets with 4331 changes to 535 files (+10 heads)
updating to branch default
234 files updated, 0 files merged, 0 files removed, 0 files unresolved
*** Installing firefox-5.0build1.win32.en-US.exe => c:\docume~1\mozilla\locals~1\temp\tmpj33oi8.binary\
*** Updating to branch 'mozilla-release'
pulling from http://hg.mozilla.org/qa/mozmill-tests
searching for changes
no changes found
z:\data\scripts\libs\testrun.py:289: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  print e.message
unknown revision 'mozilla-release'
*** Uninstalling c:\docume~1\mozilla\locals~1\temp\tmpj33oi8.binary\
*** Removing repository 'c:\docume~1\mozilla\locals~1\temp\tmphdknnt.mozmill-tests'

Comment 1

[u279076]

Marking this a blocker for now, but we can probably do this release without BFT automation (if we HAVE to)...

Comment 2

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

This is related to Bug 655959, which attempts to match Firefox repo names with our repo names.

This is the application.ini for the RC:

[App]
Vendor=Mozilla
Name=Firefox
Version=5.0
BuildID=20110615151330
SourceRepository=http://hg.mozilla.org/releases/mozilla-release
SourceStamp=7b56ff900c2a
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}

That means we'll try to find the equivalent mozilla-release branch in our automation, which we don't have. 

I need to clarify our branching strategy with Henrik; I'm unsure whether that release branch should be mapped to mozilla-beta on our side (since that would be the most recent automation set that would apply to an RC) or what. 

If I can find out what the destination branch is supposed to be, putting in a quick exception for mozilla-release is easy.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I have talked to Geo and I have created the 'mozilla-release' named branch. So we can go ahead and test the release candidate builds. Everything should work now.

All checkins also have to happen now to that branch.

Comment 4

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Checkins valid for the current release of the product, I assume you mean? If it's something for a later version in beta or aurora, I imagine we still check into the appropriate branch and backport as necessary?

Comment 5

[u279076]

(In reply to comment #4)
> Checkins valid for the current release of the product, I assume you mean? If
> it's something for a later version in beta or aurora, I imagine we still
> check into the appropriate branch and backport as necessary?

That's how I see it, though we will want to backport mozilla-beta to mozilla-release once we hit the RC phase.

Comment 6

[u279076]

Just put this through the paces for 4.0*/5.0* -> 5.0rc1 and it works -- thanks for the quick turnaround.

Comment 7

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

(In reply to comment #5)
> (In reply to comment #4)
> > Checkins valid for the current release of the product, I assume you mean? If
> > it's something for a later version in beta or aurora, I imagine we still
> > check into the appropriate branch and backport as necessary?
> 
> That's how I see it, though we will want to backport mozilla-beta to
> mozilla-release once we hit the RC phase.

Sure. I think the plan here is that we typically write against Aurora (I think this might be wishful thinking, but I'm willing to go with it in theory) then merge forward to beta and release as the releases move forward. 

Luckily, merges are generally much easier than backports. Worst case, you can clobber the whole destination branch with the contents of the source branch; it's really just an entire codebase moving forward with the release.

The backporting goes the other direction; if we write automated tests against Beta, for example, they also have to be backported to Aurora and nightly; in the case above, the Aurora tests have to be backported to nightly. I guess our incentive to get tests done early is less backporting. :)

We might need to spin off branches for or at least snapshot 6.0, 7.0, etc. as things actually get released, in case we need to test old builds (this might be particularly relevant for update testing, depending on how we solve the whole source vs. destination version problem). 

I think the original plan was those spinoffs instead of having a standing release branch, but if a standing channel is what releng is going to do, that's likely what we need to do too.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

With the team reorg and completely overhauled docs we will have to discuss this in detail beginning of next quarter. As long as we automate features which have been introduced by the last release we are open to check those into default first. But more to come later. Good to hear that everything worked and I had network access that time - and well a bit of spare time.