Closed Bug 543794 Opened 15 years ago Closed 15 years ago

do a staging test run of 3.7a1 and 3.7a2 releases, with updates

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

Details

I'd suggest doing them with at least a locale or two, for automation simplicity. We should also discuss whether or not we want to continue shipping alphas in a differently formatted directory layout. If we do, we'll need some tool changes to support this. Either way, we need to test that path with alphas.
We'll need to verify this is possible before we start builds for FF3.7a1. The idea here is not to provide any updates *to* FF3.7a1; its to make sure when we build FF3.7a1, we do so in a manner so that we can upgrade users *from* FF3.7a1 to FF3.7a2 or above. We have never provided updates between alphas before, so this is a new feature. As of today's platform meeting, "go/nogo" will be decided on Thursday (4th Feb), so we need to understand the scope and any risks of this by Thurs.
OS: Mac OS X → All
I don't think we need to rush this entire bug. The only thing we need to be confident in before 3.7a1 is that we can ship MARs along with it. Any time between 3.7a1 and 3.7a2 we can do the 3.7a2 test run, generate updates, snippets, do verification, etc. I don't see any reason to rush this along.
We need to at least make sure that 3.7a1 has all the right bits to point at an appropriate channel, but I agree that we don't need to do the rest. We know we can produce snippets and mars, etc., since we do it all the time, right? It's true that we haven't done alpha-to-alpha updates in the past, but we should be clear about what, from the client's perspective on update machinery, is actually different from being "alpha" and being "beta". That we happen to call this an alpha seems like it should have extremely minimal impact on how updates work, and as John said in yesterday's meeting, we have updated alpha users to beta 1 in the past, so we know that we can get them to install new code. Is that a correct understanding?
(In reply to comment #3) > We need to at least make sure that 3.7a1 has all the right bits to point at an > appropriate channel, but I agree that we don't need to do the rest. We know we > can produce snippets and mars, etc., since we do it all the time, right? Correct. > That we happen to > call this an alpha seems like it should have extremely minimal impact on how > updates work, and as John said in yesterday's meeting, we have updated alpha > users to beta 1 in the past, so we know that we can get them to install new > code. Is that a correct understanding? Yes, we routinely update alpha users to the latest beta. This is normally done at the 2nd beta -- when we start producing partials for the previous release. At this time, we update all alpha users with a complete MAR. The main things to test here are our snippet generation and update verification tools. Alphas are normally shipped in a different structure than anything else - and we may need to change that, or change our tools to support it. I cannot think of any possible client side differences here. There's no special "alpha" "beta" or "release" logic that I know of.
Don't take this the wrong way, Ben, but I love you a little.
ftr, this staging run would be done before we ship FF3.7a2, not before we ship FF3.7a1. Nothing to do here before FF3.7a1.
That is great news -- is there any other verification or investigation of this stuff that needs to happen before we roll the alpha? Just want to be super-clear that we've done what comment 1 meant by "We'll need to verify this is possible before we start builds for FF3.7a1".
(In reply to comment #7) > Just want to be super-clear that we've done what comment 1 meant by "We'll need > to verify this is possible before we start builds for FF3.7a1". John was under the impression that we needed to do this entire test run (including a 3.7a2 test run) before we could ship 3.7a1. This isn't the case. The only thing that has to happen here that hasn't in prior Alphas is uploading MARs - which the automation will do. Everything else has to be done prior to 3.7a2.
Awesome! Great work, thanks!
Per release-drivers, we need to see what it will take to start shipping these MozillaDeveloperPreview releases in /home/ftp/pub/firefox/devpreview, rather than /home/ftp/pub/firefox/releases/devpreview
(In reply to comment #10) > Per release-drivers, we need to see what it will take to start shipping these > MozillaDeveloperPreview releases in /home/ftp/pub/firefox/devpreview, rather > than /home/ftp/pub/firefox/releases/devpreview Scratch this -- we're not going to be doing this.
Looks like I'll be doing this this week.
Assignee: nobody → bhearsum
Update generation failed on a few fronts in my 3.7a2 test run: * Update verify configs got bumped with the wrong file names/paths (used 'from="/firefox/releases/3.7a1/linux-i686/%locale%/firefox-3.7a1.tar.bz2"' when it should've been 'from="/firefox/releases/devpreview/1.9.3a1/linux-i686/%locale%/mozilladeveloperpreview-3.7a1.tar.bz2"') * Patcher config got bumped similarly wrong I'm going to run through update generation and verify with manually created config files to see if there's other issues.
After manually creating configuration files update and snippet generation went smoothly, as did linux and mac update verify. Windows update verify uncovered the fact that the MAR and the EXE ended up with different binary contents. I suspect this happened due to MOZ_APP_NAME and MOZ_APP_DISPLAYNAME differing, but I haven't verified that yet. This is probably an issue that's been around forever, but not encountered since we've never generated partials between Alphas, and always updated Alphas with a complete MAR. One other thing I forgot to mention was an issue with mac MAR generation, also caused by MOZ_APP_NAME and MOZ_APP_DISPLAYNAME differences. The details of it are in bug 540833.
Depends on: 540833
Removing blocking, since 3.7a1 -> 3.7a2 updates have been deprioritized. Filed bug 546703 to track issues related to alpha -> alpha updates.
No longer depends on: 540833
With the tracking bug filed for follow-up issues here, I don't think there's anything left to be done -> FIXED.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.