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
