Qin Ubuntu ISO for PRC (China)

pitti, 2011-05-19:
- I don't actually know how to set up cdimage to build a new image set, so I reassigned this to cjwatson; alternatively I'm happy to have a training session with Colin and then do it myself.
- I'd suggest to seriously reconsider gufw; having to configure port numbers and IP address ranges is not something we want to present to users in a default install. We have some plans to provide a simpler and more robust roaming/profile-based firewall integrated into network-manager. guwf is not suitable for main ATM, as it does not have a real maintainer right now.
  - gekker: We can go with the basic UI for firewall configuration proposed in the NetworkManager blueprint for Oneiric. If that doesn't make it in then we'll need to include gufw in OEM images, as it doesn't sound like we want to include it in the base platform image.
  - gekker: firewall config is postponed in NetworkManager, so it won't make it in (https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-desktop-network-enhancements)
- unity home dash icons are not customizable right now
  - kyleN: I created bug 785840 for this and linked it.
- customized launchers in classic mode would turn up as icons in the panel, not desktop files in ~/Desktop. Wouldn't that be more appropriate? We have had a policy of not cluttering the desktop by default in Ubuntu from day one.
   - kyleN: @gekker: Can you also please respond to this ^. Our (OEM) maverick version of Chinese Ubuntu had a requirement for desktop icons for certain required apps, I believe because they were considered easier to find and therefore increased usability among rural Chinese people who may not have computer experience. Is this still a requirement? Is supporting Classic desktop still a requirement? If not, then the issue goes away.
 - gekker: We don't need desktop icons per se. If Unity-2d is the fall back in oneiric, then no need to support the classic desktop at all. If we still have the classic desktop then we we could put the icons on the panel as pitti recommends rather than on the desktop.
- promoting gwibber plugins to main should be harmless and doable.
 - kyleN I have added this as a work item for gekker below.
- is there anything in the whiteboard session notes which you'd like to keep? I don't see anything valuable which isn't already in the wiki spec. Whiteboard should be cleaned for easier reading and avoiding duplication. (kyleN: done)
- removing whiteboard work items which are already linked bugs (the WI tracker considers them WIs as well), or covered by desktop-o-cd-localization
- setting to "drafting" until above questions are resolved or confirmed, otherwise I'm quite happy with this. Thanks!

kyleN, 2011-05-20:
@dpm: you have three work items below. the one about including specified universe pkg translations in language packs is important to this spec, the other two do not seem directly relevant. Can they be removed from this spec?
dpm, 2011-05-25:
Done. I've moved them to https://blueprints.launchpad.net/ubuntu/+spec/community-o-sustainable-translations, as I still want to keep track of them and get them done this cycle. The reason I initially added them to the current spec is because the question on how translation bugs are tracked and how the process could be improved came up in the UDS discussion

dpm, 2011-05-25:
In order to import universe translations and ship them in language packs we need:
* A trivial patch to pkgbinarymangler and get its tests updated. Estimated time 15 m.
* A small patch in Launchpad to stop ignoring universe translation tarball uploads.
* Research on how the amount of universe translations compare with those from main. Results:
  - We ship a total of ~1.25 GB (1252512038 bytes) of translation data as the sum of all language packs
  - We ship a total of ~0.85 GB (845977204 bytes) of translation data as the sum of all universe packages
  - This means universe translations have roughly 70% of the size of the translations we ship in language packs
* A decision from the research action above on whether to ship separate language packs or not
* If we decide to ship separate universe language packs, a (not too hard) modification to langpack-o-matic to generate them.

Other notes:
* IIRC, from the previous UDS discussion in Brussels, we'd only want to enable this for selected universe packages, those which are well maintained, since this would introduce a delta with those packages coming from debian (the delta being the .pot building rules).
* The discussion at UDS-O was not about mass-enabling universe translations, but rather the context was about enabling them for some packages in which we'd want to have more flexibility with translations and be able to ship updates in language packs without requiring a main inclusion request for the package. An example is the nanny package, which OEM distributes in their images.
* So as we're not talking about enabling all universe, a start would be to add a way to whitelist selected universe packages and decide to ship them in the regular language packs
   * Implementation options:

     1. pkgbinarymangler whitelist: right now pkgbinarymangler already
        builds universe translation tarballs and Launchpad ignores them.
        Keeping this approach and importing selected packages would
        require a whitelist both in pkgbinarymangler and Launchpad.
     2. pkgbinarymangler universe disabled + whitelist: modify
        pkgbinarymangler to stop from building universe translations,
        build them only for main plus the whitelisted universe packages.
        Launchpad imports anything thrown at it and the whitelist needs
        to be maintained on pkgbinarymangler only.
     3. Special header for universe packages: add an
        "XS-Ubuntu-Use-Langpack: yes" header to the debian/control file
        of each package we want to import the translations of. It would
        require a modification in each package and in Launchpad (so that
        it reads the special header)

Having talked to pitti and danilos, either 2. or 3. would be the preferred options, 2. being the one which would require less work. On 3. a non-trivial amount of work would probably be required in Launchpad,

Note, some of this will have a more general solution in https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-cd-localization

Work items for oneiric-alpha-3:
[gekker] determine best GUI pkg for the firewall (gufw may be superceded): DONE
[dpm] Check out with the Launchpad team how exactly can universe translations be enabled: DONE
[pitti] install ibus-sunpinyin for zh-hans: DONE
[pitti] drop bopomofo for zh-hans, pulled in by ibus-pinyin: DONE
[cjwatson] Checkbox to accept additional, configurable, non-free items (i.e. Hanyi fonts, Broadcom driver, etc.): DONE

Work items:
[cjwatson] produce and publish initial qin ubuntu iso: DONE
[pitti] create ubuntu-defaults-zh-cn pkg with noted customizations: DONE
[pitti] add extra web launchers to ubuntu-defaults-zh-cn once we get a license for their icons: BLOCKED
[gekker] complete main inclusion report for gwibber sohu and sina plugins. Evaluate promotion of other pkgs: DONE
[pitti] Ensure that the desired ibus backend is active by default for the desired language selection, i. e. sunpinyin for zh_CN: DONE
[cjwatson] Look at language installer/language-selector for proper handling of language selection/settings: DONE

pitti, 2011-07-20: Full version of -defaults-zh-cn does not have the requested launchers, as these are blocked by getting redistributable and free icons (currently being discussed between OEM and legal). It has been tested and verified that adding them works, though.

pitti, 2011-08-29: You can build the Chinese image out of oneiric by installing ubuntu-defaults-builder and running

  ubuntu-defaults-image --locale zh_CN --components main,restricted,universe