<> = 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