Oxide

Revision 4 as of 2014-04-17 13:50:46

Clear message

DRAFT

Oxide is still coming online. It will have a daily build PPA for merges, but it will also have other PPAs to track Chromium Content API upstream releases. We'll need to evaluate if we do autolandings or source package uploads. For now we are doing source package uploads.

Release management plan

Upstream chromium has a release cycle that consists of a development branch, a beta branch and a stable branch. Upstream pushes lots of changes to the development branch and when they are deemed ready, they are pulled into the beta branch. The stable branch is then updated to pull back verified changes from beta. The cycle for development branch to stable is approximately 12 weeks.

For Oxide, we want to track all three branches, but only have stable in Ubuntu. Chromium security, bugfix, performance and web compatibility updates will be delivered via Oxide by pulling back from the stable branch only. This allows us to pull emergency stable fixes quickly and also allows us 6-12 weeks of time to deal with changes in the development branch of chromium. All stakeholders (eg, webbrowser-app, webapp-container, UbuntuWebView, security) should also be testing the Oxide branch corresponding to the development branch of chromium to give plenty of time to discover and fix issues that affect Oxide so that we are prepared when the hit chromium stable. Every release of Oxide in the distribution will be on the latest chromium stable release (ie, 14.04, 14.10, 16.04, releases of Touch, etc will all have the same chromium version). Oxide itself will provide the stable API for applications and hide all of the underlying chromium changes.

Getting there

At the time of 14.04 LTS release, Oxide was still on the development branch and the goal is to move to the beta branch a few weeks after release and then later move to the stable branch. This should happen in plenty of time for 14.04.1, which aligns well for Ubuntu Touch and 14.10.

Since we are still using the development branch for the time being, we will initially create a branch based on Oxide r516 for bug fix updates to Oxide (r516 was chosen because it has required chromium updates, was well tested but did not fix 1307709 in time for release and we wanted to minimize changes to fix 1307709).

We will exercise the 'getting there' plan on Oxide trunk and track the chromium development branch for now (moving to beta and stable as described). Until Oxide trunk is on stable, for 14.04 we will use the trusty branch and coordinate Oxide trunk/chromium updates to this branch with the webapps, webbrowser and security teams. This will be done through iterating on PPA builds for trusty-- once they are fully tested and vetted, we will push to trusty via SRU/security updates then update the trusty branch accordingly.

MP Submission Checklist

Note: Please ensure you include the following form filled out and submitted along side your code to the MP ticket.

  • Is your branch in sync with latest trunk (Eg bzr pull lp:oxide) and packaging branch (bzr pull lp:~oxide-developers/oxide/packaging.trusty)
  • is debian/changelog properly formatted in the MP? (Oxide uses source package uploads for now)
    • use standard Ubuntu versioning

    • make sure the distribution name is set to the devel release (eg trusty)

    • add your changelog entries
  • Did you build your software in a clean sbuild/pbuilder chroot or ppa?

  • Did you build your software in a clean sbuild/pbuilder chroot or ppa on armhf? (needed for TestPlan)

  • Has your component TestPlan been executed successfully on emulator/armhf Touch build (eg, one of N4, N10, N7 (either), Galaxy Nexus) and clean Ubuntu Desktop VM?

  • Has a 5 minute exploratory testing run been executed on an armhf Touch build (eg, one of N4, N10, N7 (either), Galaxy Nexus) and clean Ubuntu Desktop VM?
  • If you changed the packaging (debian/), did you subscribe a core-dev to this MP?
  • What components might get impacted by your changes?
  • Have you requested review by the teams of these owning components?

MP Review Checklist

Note: Please ensure you include the following form filled out and submitted along side your code to the MP ticket. Note: A Reviewer usually is responsible for a single component; since we ask for reviewers to be subscribed that might see an impact by this MP this mean that we get one-to-many reviewers contributing to the MP review process.

Below the checklist that a reviewer should follow taking the viewpoint of his component, which might or might not be the same as the component this MP is targeted against.

  • Are any changes against your component pending/needed to land the MP under review in a functional state and are those called out explicitly by the submitter?
  • Did you do exploratory testing related to the component you own with the MP changeset included?
  • Has the submitter requested review by all the relevant teams/reviewers?
  • If you are the reviewer owning the component the MP is against, have you checked that submitter has accurately filled out the submitter checklist and has taken no shortcut?

MP Landing Checklist

  • ensure that the checklists have been properly filled out by submitter and all reviewers