Closed Bug 802893 Opened 12 years ago Closed 12 years ago

[OTA update] Set up otoro_stable builds & update process to match unagi_stable

Categories

(Firefox OS Graveyard :: General, defect, P1)

Tracking

(blocking-basecamp:+, firefox18 fixed)

RESOLVED FIXED
blocking-basecamp +
Tracking Status
firefox18 --- fixed

People

(Reporter: lsblakk, Assigned: jgriffin)

Details

(Whiteboard: [ota update])

We'll want this by the end of the week so that devs & testers with otoro devices are able to stay in lock-step with our unagi testers (and devs/QA working with stable updates).

I believe this means:

otoro_stable nightly builds that can be built as stable & the associated nightly promoted_to_stable with the same script as bug 801711 implemented.

otoro_stable to otoro_stable update channel & mars (if the dogfooding_prerelease functionality is enabled here too - bonus!)

If I'm missing anything please call it out.
Currently, the mars for otoro and unagi are identical.  The only time we'd need to have separate ones is for sending FOTA updates, which we don't have the logic for yet.

marshall_law, do you think we should set up separate otoro and unagi update channels?
@jgriffin I think it would make sense to go ahead and set device specific channels up, even if they are symlinked to the same place. That way we can make changes more easily in the future.

This would also require a tweak in platform to change the default update URL, and a special MAR to update the dogfooding URLs.
We never want to have different mars built for otoro/unagi off the same rev.  I guess the project here is to allow pushing stable builds on different schedules to reduce QA overhead?
cjones, will there ever been a need to push device-specific gonk updates through these channels?  If not, I'll leave it as just one channel.
Gonk updates will always be device specific.  Gecko/gaia updates should never be device specific.
(In reply to Marshall Culpepper [:marshall_law] from comment #2)
> @jgriffin I think it would make sense to go ahead and set device specific
> channels up, even if they are symlinked to the same place. That way we can
> make changes more easily in the future.
> 
> This would also require a tweak in platform to change the default update
> URL, and a special MAR to update the dogfooding URLs.

Thinking ahead, this seems like the best way to go - who knows if we'd ever have to stop updates for one and not the other (I hope we don't have to, but best to have that option regardless).
Based on this conversation, what I plan to do is setup the otoro_stable builds with a B2G_UPDATE_CHANNEL of 'otoro_stable', which would cause update requests to go to http://update.boot2gecko.org/otoro_stable/update.xml.  

Unagi stable update channel will remain http://update.boot2gecko.org/stable/update.xml, since it is already out in the wild.

I'm not planning on making an otoro_nightly channel; the otoros can use the existing nightly update channel.  I don't see any use case for needing a separate otoro_nightly.

What this means is that when promoting builds from nightly to stable, two separate promotions will have to performed, one for unagi and one for otoro.
This is now done:  http://update.boot2gecko.org/otoro_stable/update.xml.  There is an otoro_stable build at https://releases.mozilla.com/b2g/2012-10-22/otoro_stable_2012-10-22.zip.  Otoro and unagi nightly-> stable promotions are performed separately.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.