Bit more of a complete reply - sorry for the delay! Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN [email protected] || @chrisdavidmills
On 3 Jun 2014, at 13:18, Johannes Bauer <[email protected]> wrote: > Hey Chris, > > On 03.06.2014 13:00, Chris Mills wrote: >> One thing I will say is that the OS is getting better all the time. I’ve >> been dogfooding a 2.0 build for a little while, and there are a lot of UX >> improvements found there. > > Hm, would you recommend 2.0 for dogfooding purposes? Or which version is > recommended for non-development work? It would be helpful if there was a > recommendation on what branch people should build (at the time I flashed > my phone that was 1.2). I find each successive version better - I’ve been using 2.0 for a little while, and it is a much smoother experience than 1.2/3. In addition, there’s way more developer features to play with, and the browser is a bit less crashy. > >> We also have mozilla.org Firefox OS release notes, for example: >> >> http://www.mozilla.org/en-US/firefox/os/notes/1.2/ >> >> These are where the more use-centric information is kept, so I decided to >> just make the MDN stuff developer-focused. > > Aaaaah, thank you! That is precisely what I was looking for. Don't know > why I couldn't find it, when I google "firefox os changelog" now it's > the first hit. I didn’t hack Google, so I don’t know what happened here ;-) I’ll link it more obviously anyway. > >> But perhaps I should make these more visible with a link up the top, rather >> than just at the bottom of the huge list of dev changes? > > I think a link to those would be really great! Are there user-release > notes for 1.4 too? Not yet; they’ve got up to 1.3 so far: http://www.mozilla.org/en-US/firefox/os/notes/1.3/ > >> Another issue I should flag here is that, for a lot of build wants, we are >> at the mercy of the phone manufacturer/OEM to provide easy-install builds; >> licensing issues in many cases prevent us from just issuing builds, so we >> have to wait for the phone companies to make them available. Some companies >> (such as geeksphone) have been great at providing up to date builds to Flash >> to your phone, some not so great. > > Yes, I understand there are vendor-specific components. > > One problem for me is that I cannot tell which components are > proprietary (vendor-specific) and which aren't. During the build process > the phone has to be hooked up so it can fetch these proprietary files. > It's not transparent to me where these files end up and how I can back > them up properly. > > This also means that rebuilding a whole tree after a long time is > difficult, because all the fetch-proprietary-things step has to be done > again. Would it maybe be possible that the installer fetches the > proprietary files and creates one single file (proprietary.tar.gz) that > I could download once from my phone and then just drop-in into my build > tree? > > That'd be rather cool since I could have my proprietary.tar.gz backed > up, remove the tree after 6 month, reclone everything, drop in the > tar.gz and just rebuild (and end up with a working image). This sounds like a cool idea, but I don’t know how possible it is. Anyone got any thoughts? > >> It’s not just as simple as downloading a new browser to your desktop. >> Apologies if you already knew all this, but I just wanted to make sure, as >> many people miss this detail. > > I agree that this issue is not transparent enough. And actually when I > first installed the phone I ended up bricking it (wouldn't detect the > SIM card). Back then I got pointers to the mailing list, but it would be > really cool when there was some documentation about what the reasons are > for this and (probably even more important) how to fix them. I try to keep this information for different devices at https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide But it has been quite tricky to get hold of the information. I am making a few breakthroughs recently though. > > Thinking about it, maybe I'll write a wrapper script that does exactly > what I propose. That will clone the different repos, have some > rudimentary i18n support (will create these json files for instance) and > will be able to extract and re-feed that proprietary.tar.gz tarball. > Maybe I think I could play around with it some more and give it a shot. that does sounds really cool! _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
