Closed
Bug 1252427
Opened 9 years ago
Closed 7 years ago
Remove FTU app
Categories
(Firefox OS Graveyard :: Gaia::First Time Experience, defect)
Firefox OS Graveyard
Gaia::First Time Experience
ARM
Gonk (Firefox OS)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: gwagner, Assigned: sfoster)
References
Details
Attachments
(1 file)
(deleted),
text/x-github-pull-request
|
Details |
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?
Reporter | ||
Updated•9 years ago
|
Flags: needinfo?(sfoster)
Assignee | ||
Comment 1•9 years ago
|
||
I'm working on this.
Assignee: nobody → sfoster
Flags: needinfo?(sfoster)
Comment 3•9 years ago
|
||
Assignee | ||
Comment 4•9 years ago
|
||
(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.
Assignee | ||
Comment 5•9 years ago
|
||
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.
Assignee | ||
Comment 6•9 years ago
|
||
(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)
Updated•9 years ago
|
Status: NEW → ASSIGNED
Comment 7•9 years ago
|
||
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)
Assignee | ||
Comment 8•9 years ago
|
||
(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)
Comment 9•9 years ago
|
||
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)
Comment 10•9 years ago
|
||
A Pivotal Tracker story has been created for this Bug: https://www.pivotaltracker.com/story/show/116996085
Assignee | ||
Comment 12•9 years ago
|
||
(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)
Comment 13•9 years ago
|
||
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)
Assignee | ||
Comment 14•9 years ago
|
||
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)
Assignee | ||
Comment 15•9 years ago
|
||
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.
Assignee | ||
Updated•7 years ago
|
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.
Description
•