FirefoxTranslationsPlanning

Session Notes

= Translations for Firefox in Lucid =

== Lucid ==

 * One version
 * Upgrade to a new version during in stable releases as well (eg. from 3.5 to 3.6, which is a security release)
 * Worry about language pack updates: we would have to roll out updated language packs together with firefox updates; two solutions:
   * Upload en-US.xpi, all translations prior to uploading actual package; use regular language pack updates, but prepare them just in time for when firefox is going to be built
   * Manually export only firefox translations, integrate them into latest language pack export

 * Template concerns: firefox-3.5 vs firefox-3.6 (switch probably in December)
   * Export full translations and import them into new template
   * Use unversioned templates
   
== Translation updates for 3.6 ==

 * Arne mentions that there is a bug - not possible to change source path in FF template

 * Arne to upload all templates (Hardy, Intrepid, Jaunty, Karmic)
 
 * We'd like to export and ship only Firefox translations on an update - QA'ing all translations (GNOME, KDE, etc) for all releases would be quite risky - difficult to get feedback from users for all releaes
 * Manual export of FF translations only and put them on language packs - but full tarball export, extracting the Mozilla bits

 * Not necessary for xulrunner - xulrunner to disappear - to be moved to Universe, all xulrunner translations to be moved to Firefox

=== QA ===

 * List of languages that don't use the xpis
 * List of languages with changes
 * We should be extra careful with Hardy

== agenda ==

 * how to better utilize devmode
  * export in upstream format
  * export changes only
  * export changes as upstream patch
  * at export time inform users how to create xpi from the xpi.po file 
 * feedback loop
 * localized searchplugins - technical implementation, etc.

== Actions ==

 * David to communicate with the translations community to see if there is
   interest in scripting the steps to submit to upstream
 * David to get feedback from the community about devmode and changes

Additional Notes

Background:
 * most CVEs in the archive
 * 

History:
 * Mozilla has kept stable release branch upgraded (security and major fixes)
 * typical: 40 CVEs, 120 fixes per microrelease
 * promise of 6 months support for previous stable after a new release; after that we did backports ourselves
 * Hardy: upstream support for 3.0 will end in December
 * even though we follow the upstream review policy, we get much less QA
 * once an LTS is released, it is hard to get testers for previous LTSes
 * Chromium: no stable support at all, rolling upgrades for all users; Mozilla seems to like that
 * Plan: Major version upgrades every 4 to 6 months, no support for previous stable at all any more

Pushing new major versions into stables:
 * packaged and user-installed addons will just stop working
 * Hardy QA wrt. other rdepends
 
 
we will need to get our extensions repackaged for each major release, every few weeks
 - extensions for the new version may take weeks to come out
 -> or remove the packages from the archive (except our own ones)
 * do not want to use upstream binaries. lose gnome (VFS, Printing, ...) integration, LP integration, compiler hardening
 
Take as granted:
 * back porting security fixes will no longer be sustainable
 * we will not be able to change mozilla policy
 
What we would need to do:
 * stop using system libraries, use bundled ones (which will double CVE tracking and exposures in these libraries, but work won't be significantly increased for these libraries -- the work will be shared potentially with firefox upstream)
 * drop xulrunner to universe, resolve remaining rdepends
 * 3rd party addons may go away from the archive for lucid; for stables: find an install.rdf hack which we ship in -updates which will cause firefox treat it as it was in the profile, and use the builtin auto-update feature
 * moving away from Firefox as default browser is considered a bad user experience and not really feasible for lucid (rendering still not as good as ffox)


Problem with openjdk - firefox 3.6 is dropping the required API support for openjdk's browser plugin. If we release Firefox 3.6 for Karmic, we'll break everyone using openjdk as a browser plugin.

Alex' s3kr1t plan for Lucid and forward:
 * drop xul runner, don't build against xul runner, ship what upstream is shipping
  * important rdepends which we can't just remove: couchdb, eclipse, yelp
 * ship without patches
 * ship with bundled library
 * no third parties releases
 * open JDK? can we upgrade to it, or we will have to remove it and have Sun Java
 * Do we plan to firefox
 * Put sun java in partner archive

current stable releases:
 * do the same for firefox, as long  as a version is supported, we force upgrades across stable releases
 * find rdepends that are exposed to web content 
 * ship the firefox with the non-system libraries
 * epiphany: push to karmic version to use webkit backend

translations plan:
 * import the new upstream XPIs manually into rosetta
 * don't build new languages
 * put them into langpack-o-matic
 * either update -base package OR
 * generally don't ship firefox translations in -base, just in updates (one-time transition for stable Ubuntus) 

Thunderbird:
 * most CVEs are not an issue, since JavaScript is disabled
 * does not need a similarly extreme thing, few remaining patches can be backported



How do we maintain this going forward
 * should discuss with QA team how to support on major version upgrades early (while can still file bugs)
 * 
 
 ACTIONS:
 * start fixing the package to start building everything in firefox without patches
 * same source  package for all stable releases
 * figure out upgrade path for packaged extensions in stables
 * create a security native PPA for the ff non-patched builds
 * review xulrunner rdepends from hardy on which apps are potentially exposed to insecure contents
  * switch to gtkhtml or webkit
  * confine with apparmor
  * ignore if they don't use javascript
 * define who does what after the transition (ie security updates)
 * rickspencer3 to schedule weekly call


CategoryTranslations

Translations/Events/UDS/Lucid/FirefoxTranslationsPlanning (last edited 2009-11-24 17:11:46 by 212)