Closed Bug 1252427 Opened 9 years ago Closed 7 years ago

Remove FTU app

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: gwagner, Assigned: sfoster)

References

Details

Attachments

(1 file)

Keeping the FTU app around and maintain it during the transition period isn't a high priority. We should move the code and tests to a separate repository so it doesn't get lost. We might want to leave the 'hooks' to create a custom FTU app in the system app but we won't maintain ours going forward. This also includes the tutorial parts. My assumption is that users don't use any functionality since they can do everything in the settings app afterwards. The work will be done on the transition branch. Sam, can you help out here?
Blocks: 1252143
Flags: needinfo?(sfoster)
I'm working on this.
Assignee: nobody → sfoster
Flags: needinfo?(sfoster)
(In reply to Autolander from comment #3) > Created attachment 8726002 [details] > [gaia] sfoster:remove-ftu-bug-1252427 > mozilla-b2g:master Based on master branch for now. There's a number of decisions to make here around what should go and what should stay. So far: * Entire apps/ftu directory: the manifest, all resources, tests - all gone * NOFTU flag defaults to true: means to supply an FTU app you'll be using a double-negative (NOFTU=0), but this seems the simplest change to make for now * Most of the system app untouched, FtuLauncher & Service.isFtuRunning still exist. But, where we depend on a specific implementation in the FTU I've removed that code. This is true for Firefox Accounts & Late Customization * FTU launch option removed from Settings app. I'll see how this fares on treeherder before soliciting feedback/reviews.
I'm seeing a *lot* of Gij failures, so I'm going to try taking this a step at a time. The current PR just removes late customization from the system app to see how that plays.
(In reply to Sam Foster [:sfoster] from comment #5) > I'm seeing a *lot* of Gij failures, so I'm going to try taking this a step > at a time. The current PR just removes late customization from the system > app to see how that plays. https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=c6c383e6c76deae9da099d8ba11a8fa684630fa1 Its still pretty bad, and unless I'm missing something, I just don't see how the current patch could cause that. Flagging :auswerk and :albertopq to see if something jumps out or if something bad happened to master.
Flags: needinfo?(aus)
Flags: needinfo?(apastor)
Status: NEW → ASSIGNED
Sam, shouldn't the Pull Request be done in top of the 'kanikani' branch instead of master? Regarding the tests, treeherder is quite unstable at the moment. I can't see any failure related to this patch either.
Flags: needinfo?(apastor) → needinfo?(sfoster)
(In reply to Alberto Pastor [:albertopq] from comment #7) > Sam, shouldn't the Pull Request be done in top of the 'kanikani' branch > instead of master? Regarding the tests, treeherder is quite unstable at the > moment. I can't see any failure related to this patch either. Yeah, I had an earlier PR against kanikani, I just rebased the last one against master to see if the instability was related to the kanikani branch.
Flags: needinfo?(sfoster)
Hi Sam, I'm honestly not sure either as to why your patch would cause these extra failures. There's a lot of instability in general in the tree these days so it's hard to pinpoint. It's possible though that some of the tests are actually requiring the ftu app, or parts of it, or shims that it normally uses for tests. I would give that a quick check if you haven't already. I unfortunately don't have any other thoughts on why it would be failing though, but maybe my thoughts above will hit the mark. :)
Flags: needinfo?(aus)
A Pivotal Tracker story has been created for this Bug: https://www.pivotaltracker.com/story/show/116996085
Hi Sam, are you still working on this?
Flags: needinfo?(sfoster)
(In reply to Ben Francis [:benfrancis] from comment #11) > Hi Sam, are you still working on this? Yeah, its still in my queue. If the builds are building I can get to it this week, though with the NO_FTU=1 change already landed, some of the work is already done.
Flags: needinfo?(sfoster)
Hi Sam, we have two weeks to go on the transition project. Do you think this work is needed or is the work already done to disable it enough? If it is needed then should we find someone else to do it.
Flags: needinfo?(sfoster)
Hi Ben, this is just a clean-up ticket at this point after Aus landed the patch to disable the FTU. So *needed* is a judgement call. I have to make sure my build still builds but can pick this back up next week.
Flags: needinfo?(sfoster)
Or, if someone else wants to grab it that would be great. Essentially it was just removing apps/ftu, and removing references to it in the distro manifest(s), tests etc.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: