Closed Bug 910128 Opened 11 years ago Closed 10 years ago

generate "flatfish" builds for B2G

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: joduinn, Unassigned)

References

Details

(Whiteboard: [Flatfish only][developer+])

Please generate nightly builds for "flatfish" devices. open questions: 0) what branches are these supported on? I'd guess gecko m-c/gaia master only. 1) do we also need per-checkin builds? I'd guess we should generate flatfish builds on same cadence as we do for other devices, but asking here in case needs are different. 2) if we need to generate updates? If yes, how to make these updates available without complicating updates being generated for other devices. 3) what locales are to be included? (blocked on getting build instructions in bug#904377, and legal info in bug#910123)
For basic customization (wallpaper, homescreen swipe rate) with Flatfish, I've setup a 'repo' that fetch both gaia and related customization folder into place https://github.com/gaia-local/gaia-local-repo/tree/tablet-master We may merge those customization into default build script, but no clear idea at the moment.
It's a must for flatfish. koi+
blocking-b2g: --- → koi+
Whiteboard: [Flatfish only]
Assignee: nobody → ttsai
+Viral hi Thomas, Viral, per talk, i know there's progress on this issue, but please still update status on bugzilla if possible
blocking-b2g: koi+ → 1.3+
(In reply to Francis Lee [:frlee] from comment #3) > +Viral > > hi Thomas, Viral, > per talk, i know there's progress on this issue, but please still update > status on bugzilla if possible Hi John, any progress on this request? We're hoping to have m-c/master flatfish builds asap, as devices will be landing into MV and SF's hands sometime this week. Thanks, Tony
Flags: needinfo?(joduinn)
Askeing have setup a flatfish master build in TWCI to facilitate test progress in early stage, maybe he can help.
Flags: needinfo?(fyen)
TWCI get the source code from private bitbucket repo (due to bug#910123 ?) and generate the flatfish daily build now. MV and SF can try to download builds from TWCI before this bug be resolved.
Flags: needinfo?(fyen)
base on comment#6, we have a temporary solution. but we still need to fix this issue.
Whiteboard: [Flatfish only] → [Flatfish only][developer+]
(In reply to Tony Chung [:tchung] from comment #4) > (In reply to Francis Lee [:frlee] from comment #3) > > +Viral > > > > hi Thomas, Viral, > > per talk, i know there's progress on this issue, but please still update > > status on bugzilla if possible > > Hi John, any progress on this request? We're hoping to have m-c/master > flatfish builds asap, as devices will be landing into MV and SF's hands > sometime this week. > > Thanks, > Tony tchung: No progress, this bug still blocked on bug#904377 - basically, still waiting for someone to show us *how* to do these builds manually. I also see akeybl asking for those instructions in bug#904377.
Flags: needinfo?(joduinn)
I'm unsure why this would be 1.3 blocker specifically, as I don't recall work happening for flatfish on any branch other than trunk. Renominating for more discussion.
blocking-b2g: 1.3+ → 1.3?
hi release management team (ni catlee, since John left), in comment1, for your questions: 0), yes, gaia/gecko master only. 1), yes, let's follow the general process 2), build instructions in bug#904377 is finalized and it will be landed soon. once its completed, i believe you will have what you need. for any detailed information, Danny Liang/Thomas Tsai can help you. by the ways, OTA is required, could you please let me know how long it take to enable OTA service for Flatfish? since contribution program will be launched around E/Feb.
Flags: needinfo?(catlee)
Enabling OTA updates for Flatfish is pretty straightforward once we have the builds going.
Flags: needinfo?(catlee)
Whiteboard: [Flatfish only][developer+] → [Flatfish only][developer+][BLOCKED BY 904377]
It has been done.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to thomas tsai from comment #14) > It has been done. So, where are those Mozilla-generated Gecko+Gaia builds? Is delivering (F)OTA updates for them also done as I'd expect when this is marked fixed? My expectation is to have nightly/master Gecko+Gaia generated by Mozilla with daily updates available, which we can install/flash onto a base image delivered by the vendor - just like we have for Flame.
Flags: needinfo?(ttsai)
There is no PVT build yet. But you can get 7 days' build: https://www.dropbox.com/sh/b2py1btcwstqldl/AABblbq_csa1IHQwdvLdfptTa And TCP at https://wiki.mozilla.org/FirefoxOS/TCP
Flags: needinfo?(ttsai)
(In reply to thomas tsai from comment #16) > There is no PVT build yet. But you can get 7 days' build: > https://www.dropbox.com/sh/b2py1btcwstqldl/AABblbq_csa1IHQwdvLdfptTa OK, then this bug is not fixed as it's about Mozilla release engineering creating builds, not about something being available on dropbox (built by partner or whoever). It might not be clear from the comment that it was filed for those builds, but :joduinn was the head of Mozilla releng at that time, so it's implied by that and him doing all the coordination back then on what releng was building. Also it's filed in the product for Mozilla release engineering, which gives another hint on the intent being them doing the builds.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It's nearly a year since this bug was first filed, so needs are likely to have changed. Given we have builds from our partner (links in comment #16), do we still wish to have flatfish builds from Mozilla releng ? If so, lets revisit the the questions in comment #0.
Whiteboard: [Flatfish only][developer+][BLOCKED BY 904377] → [Flatfish only][developer+]
FWIW, bug 957957 is very similar to this one and WONTFIX.
I was in a tablet program coordination meeting last week, and it sounded very much like we'd want flatfish Gecko+Gaia builds from Mozilla releng for master/nightly branch with daily updates, similar to what we have for Flame. Putting a need-info on Asa, who is leading the tablet program, for confirmation of that.
Flags: needinfo?(asa)
Asa, do you have any news on this bug ?
FWIW - I'll be on the hook for this once we have more news to go by. If we can get a sense of priority too that be great so I can properly schedule my goals. :)
We'd like to be able to "shallow flash" the Flatfish tablets like we do the Flame, using the latest Gecko/Gaia from Mozilla and the Mozilla OTA setup for daily updates of said shallow flashing. All phone projects are higher priority than the tablet program, but if there's a way to provide this like we do for Flame, it would help the program greatly. What's involved in providing what we do for Flame? Is there an opportunity for volunteer help setting this up? (We did empower several hundred "programmer" types with the Flatfish tablet hoping that would include people who could make this kind of thing happen without too much cost to the core OS team.)
Flags: needinfo?(asa)
In principle the machinery is all in place. The work for RelEng in making sure that any repositories are synced down to our local mirror, setting up some configuration in the gecko repo, and that the build works within our environment. I'll leave it up to jlund to say he's prepared to mentor someone on this work (depends how much requires internal systems I think), and how this sits compared to his other priorities. Thanks for taking it on! Asa, what branches should we do builds for ? Some options would be 'just 2.0', '2.0 and higher', 'just 2.1', '2.1 now, and higher later'. We'll need to do nightlies to get updates, and possibly periodic builds to help narrow down regressions from code changes (every 3 or 6 hours depending on branch).
Assignee: ttsai → jlund
(In reply to Nick Thomas [:nthomas] from comment #24) > Asa, what branches should we do builds for ? Some options would be 'just > 2.0', '2.0 and higher', 'just 2.1', '2.1 now, and higher later'. We'll need > to do nightlies to get updates, and possibly periodic builds to help narrow > down regressions from code changes (every 3 or 6 hours depending on branch). In an ideal world, we'd have a master/m-c channel and a previous release channel, so 2.1 "unstable" development channel and 2.0 "stabilizing" channel, both with daily updates. I don't think the more frequent builds would be particularly valuable at this stage and when we do get to a place where we've got more people working on tablets, we may have different "reference" hardware.
Given my lack of understanding of this stuff, apologies if I'm just adding noise and asking a laughable question, but the vendor currently has builds going, so perhaps we could ask them for their config files if it would help us to jump start the setup process.
(In reply to Caspy7 from comment #26) > Given my lack of understanding of this stuff, apologies if I'm just adding > noise and asking a laughable question, but the vendor currently has builds > going, so perhaps we could ask them for their config files if it would help > us to jump start the setup process. Note sure how much we even need from that, other than possibly a copy of the drivers, if that's needed to get compilation going (even though we actually only need shallow Gecko/Gaia builds/updates that run on top of those vendor builds). As a note to releng, what we want that those builds do not provide is updates, knowing what exact code is used (and being as near as possible to pristine in-Mozilla-repos code, I assume that's what releng uses anyhow) - and build symbols on Mozilla servers so that our crash reports make sense. :)
cool. I am a bit swamped with tasks so unless there is heavy push back, I intend to look at this next week.
(In reply to Robert Kaiser (:kairo@mozilla.com, slow reaction due to vacation backlog) from comment #27) > Note sure how much we even need from that, other than possibly a copy of the > drivers, if that's needed to get compilation going (even though we actually > only need shallow Gecko/Gaia builds/updates that run on top of those vendor > builds). The main thing is that * https://github.com/mozilla-b2g/b2g-manifest/blob/master/flatfish.xml is up to date * QA or a dev with a device (with a good image on it), and a build environment, can provide the backup-flatfish which a build produces (preferably as backup-flatfish.tar.xz). Plus any additional drivers needed. > As a note to releng, what we want that those builds do not provide is > updates, knowing what exact code is used (and being as near as possible to > pristine in-Mozilla-repos code, I assume that's what releng uses anyhow) - > and build symbols on Mozilla servers so that our crash reports make sense. :) Could you clarify what you mean, particularly the first line. Seems to be missing a word which makes it unclear what you're asking for re updates.
(In reply to Nick Thomas [:nthomas] from comment #29) > (In reply to Robert Kaiser (:kairo@mozilla.com, slow reaction due to > vacation backlog) from comment #27) > The main thing is that > * https://github.com/mozilla-b2g/b2g-manifest/blob/master/flatfish.xml is up > to date I heard there's people who can do builds, so I hope it is up to date (I unfortunately broke my B2G build system with toolchain updates at some point but I'm happy to help where possible). > * QA or a dev with a device (with a good image on it), and a build > environment, can provide the backup-flatfish which a build produces > (preferably as backup-flatfish.tar.xz). Plus any additional drivers needed. We have a number of people running the vendor-provided master builds, so I hope that's easy. I'm also happy to help there if possible. > > As a note to releng, what we want that those builds do not provide is > > updates, knowing what exact code is used (and being as near as possible to > > pristine in-Mozilla-repos code, I assume that's what releng uses anyhow) - > > and build symbols on Mozilla servers so that our crash reports make sense. :) > > Could you clarify what you mean, particularly the first line. Seems to be > missing a word which makes it unclear what you're asking for re updates. Everything after the first "is" are things we'd like to have (via Mozilla builds) and we don't have right now. Everything before that "is" is just the introduction of "this is what we want and what the vendor build do not provide yet". For updates, if we get nightly channel updates, we are really happy! :)
Hi, Nick I can provide you with the latest backup-flatfish so you can build your own images. As we are not allowed to share these blobs publicly, I'm writing you an email with the proper link. https://github.com/mozilla-b2g/b2g-manifest/blob/master/flatfish.xml file is up to date, it has been updated recently because some new bluetooth integration. This integration is cuasing build errors right now so you won't be able to build anything so far (I'm working on it).
I was unable to look at this this week and next week I'll be on buildduty so if I still end up tackling this myself, it won't likely be finished until the end of the following week after buildduty. We are in the middle of planning and scheduling changes to b2g related things. To help paint a clear picture, could you post in the bug and exact date of when you would like this to be completed and its level of urgency? It can be rough :) It might change who does what and when. I know it was previously said that it was lower on priority then phones but getting expected dates and a sense of what this is blocking would certainly help organizing on our end :) thanks!
FWIW, Foxconn makes images available at https://www.dropbox.com/sh/b2py1btcwstqldl/AABblbq_csa1IHQwdvLdfptTa/ (the stable directory has one that actually works), so those we want to be using as base images (and to feed the necessary backup-flatfish files to Mozilla's build process - of course, Mozilla can't redistribute those files) and then Flash a Gecko+Gaia nightly/master build from Mozilla with daily updates on top of them. (In reply to Jordan Lund (:jlund) PTO till 27th from comment #32) > We are in the middle of planning and scheduling changes to b2g related > things. To help paint a clear picture, could you post in the bug and exact > date of when you would like this to be completed and its level of urgency? > It can be rough :) It might change who does what and when. Only Asa, who is leading the program, can give any any of that.
Flags: needinfo?(asa)
Assignee: jlund → nobody
Can someone with experience in this area comment on the engineering effort required to set this up? It is a low priority, but one we'll need to invest in if we're going to keep the TCP going, something that's being actively discussed right now.
Flags: needinfo?(asa)
Will add this to our TC todo list
What are these and do we care about this anymore?
Flags: needinfo?(jlal)
Yeah this is a WONTFIX at this point.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Flags: needinfo?(jlal)
Resolution: --- → WONTFIX
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.