If you want me to write a startup guide for Gaia, I can do that. Like a really noob article. On Jan 10, 2014 11:56 AM, "Chris Mills" <cmi...@mozilla.com> wrote:
> > On 10 Jan 2014, at 15:43, Adrian Custer <a...@pocz.org> wrote: > > > On 1/9/14, 5:26 PM, Chris Mills wrote: > >> Hi all, > >> > >> Hope you are having a good start to 2014! > >> > >> One of my first tasks this year is to restructure the Firefox OS zone > on MDN (https://developer.mozilla.org/en-US/Firefox_OS). There is some > good content on there, but it could really do with the flow of content and > structure improving. I have started to devise a plan at > >> > >> https://etherpad.mozilla.org/mdn-fxos-zone-restructure > >> > >> If you have any feedback about what could be improved on the Firefox OS > content zone and what you think of this plan, please let me know, by > responding to this mail, or writing your feedback into the “FEEDBACK > SECTION” near the bottom of this doc. It’s at an early stage, but I reckon > a bit of restructuring will really sort this out. > >> > >> Best regards, > >> > >> Chris Mills > >> Senior tech writer || Mozilla > >> developer.mozilla.org || MDN > >> cmi...@mozilla.com || @chrisdavidmills > >> > >> > >> > > > > Hey Chris, > > > > Your etherpad is a start. However, there is a bunch of work needed to > get a good structure for the docs going forwards. > > > > > > I took action a few weeks ago to work on this. Unfortunately, I got side > tracked quickly into trying to fix things rather than trying to document > the mess as is. As far as an outline, this is as far as I had gotten: > > > > > > Landing page > > (pictures and redirects to sections or to other sites) > > > > Introduction > > * Define Firefox OS as both a *project* and an *OS* > > * Current status > > * 2013 > > * 2014 plans > > * This site is for: $audience_list > > * Other resources (also, resources for $non_audience) > > > > The Firefox OS Project > > * Mozilla -teams > > -community > > * Android project (via codeaurora.org) > > * Device makers (?the new alliance?) (e.g. QCOM) > > * Device assemblers (e.g. Alcatel) > > * Device distributors (e.g. Movistar) > > > > The OS > > * Overview > > * Detailed architecture of the pieces > > * ... > > > > Building > > * Overview > > Build Types: Device, Emmulators, Desktop > > Build components: Android tools, Profilers, Output Dir, Images > > Feature support chart > > The build process: workspace, goals, steps > > Caveats: disk size, network bandwidth, compile times > > * The workspace > > Layout > > Uses (build, code w/repo, code w/ git) > > * Pre-reqs > > * Configure > > * Build > > * Run? > > * Install > > * Customize > > > > Using the build > > * Screenshots > > * Remote Debugging > > * Profiling (and memory usage) > > * Remote control of a device > > > > How to file bugs > > * These docs > > * App Manager, Simulator > > * FF Responsive design View > > * FF Developer Tools > > * Gaia Apps > > * Gecko on Gonk > > * The build workspace > > > > Developing Firefox OS > > * Working in the workspace > > * repo in the workspace > > * git in the working dirs > > * linking in separate working dirs > > * How to contribute: Gaia, Gecko/Gonk, Gonk, Docs... > > > > Devices > > * ZTE Open > > * Alcatel OneTouch Fire > > * ... > > > > > > So that's not much better than your etherpad. Its not comprehensive yet, > it does not flesh out any of the topics, and does not consider what else is > needed. This view adds, compared to your etherpad, the idea of discussing > the 'Project' and its 'community' which are important to outsiders and for > building a community (although that may not be something this project wants > or wants enough to invest in). > > > > There is some good stuff in here, and I have worked all this in to produce > another iteration of the new structure (see the Etherpad.) > > > > > > > > However, while working on the docs and thinking about the various users, > it became clear that we should at least try to do better than the current > build system. So, in the last few weeks, I have been trying to get a handle > on the build. I spent a couple of weeks hacking a bash script framework to > manage a Firefox OS 'workspace'. The framework allows for a number of > 'phases' (e.g. bootstrap, configure, build, run, install, configure) each > of which might have a number of stages. Thus we could do: > > fxos setup > > and get the result attached to this email. (Really, it just tells a user > what their machine needs for the different parts of the build, i.e. what is > needed in the bootstrap.) The script framework should make it easy to > isolate the code that does stuff from surrounding code that documents what > has been done and what is needed. These days I am wrangling with repo and > git and the various workspace configurations which are possible, (i.e. repo > mirrors, single branch clones, shallow clones, group based manifests). I > still have a ways to go on this but it might eventually get somewhere. > > > > I’m just documenting what the developers do; I admire your enthusiasm, and > hope it leads to some improvements. > > > > > > > It seems, from the general silence on the dev-b2g list, that there won't > be much help coming from there. So we will have to invent a semantic > structure to Firefox OS itself that we can then document. Unfortunately, > since most of the details are over our heads, our readers will suffer from > our lack of understanding. Technical debt begets more technical debt. > > > > From inside Mozilla, it would be of use to find out from recent hires > working on Firefox OS what information they found they needed to become > effective contributing. There's surely a lot that passes by word of mouth. > > A lot of this will start to come out when I start researching what to put > in the “Hacking and developing Firefox OS section”, and asking questions. > This is the biggest part that’s missing right now. > > > > > Also, I have *no idea* about any of the runtime scripts in the B2G > project: what they do or what tools they work with. So the whole 'using the > build' section is out of my league. I suspect the tools should really have > been part of some separate project but are only part of the default build > because that was the path of least resistance and there was no mechanism > for optional inclusion. > > > > Finally, I started adding to your etherpad but that work led to this > email instead. > > > > > > Not sure how you want to go from here. Probably this discussion should > move to the docs list. > > I have cross posted it on the dev-mdc list too; some more insights should > come from there. We’ll move forward. > _______________________________________________ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
