The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.
Native Client‎ > ‎2: How Tos‎ > ‎

How to backport changes to older SDKs


Background

Developers for any platform often choose a version of the SDK and keep using it until they make a release or finish a huge milestone. It could take months or even years before the developers have time to switch to the new SDK, adapt their code to new APIs ets. A good example is Chrome on Windows: Chrome developers began switching to Visual Studio 2010 only in the year 2012.

On the other hand, developers often hit the problems that are fixed in the SDK's trunk. Some of such fixes can theoretically be "backported" to the old SDKs (compiler, untrusted libraries). We had cases in NaCl history when a developer hits a nacl-gcc bug or a NaCl threading bug (in untrusted code) that gets fixed in trunk and does not get distributed to developers until after several months.

The main requirement for a fix to be the kind that can be "backported": it must not change the ABI, which roughly means that a developer should be able to link with the SDK-with-fix without recompiling their code previously compiled with the SDK-without-fix. Hence, changes that eliminate a compiler crash (without affecting code that compiled before) are safe for backporting.

Long Term Support (LTS) SDK releases

About 9 SDK versions get released every year, aligned with the Chrome releases, adding support for new features appearing in Pepper interfaces shipped with Chrome. This is quite a lot of work to support all SDK releases in the time frame of two years.

Currently (June 2012) we only support 3 SDK releases that correspond to Chrome channels: stable, beta and dev. There is no Long Term Support for SDK releases now.

How to backport a patch for the toolchain

The toolchain changes are the hardest case for backporting than the rest of the SDK. We will focus on the toolchain in this howto.

If your patch to parts of a toolchain does not affect the toolchain/pepper ABI, and makes life of a developer using NaCl SDK significantly more comfortable, backporting the change to LTS SDK is a multi-step process:
  • Make the patch committed to the Git toolchain sources
  • Update the native_client/tools/REVISIONS to trigger toolchain bots for building the new toolchain revision
  • Make the native_client tree use the new toolchain and run tests with it. There is a howto for updating the toolchain DEPS in native_client by using the find_toolchain_revisions.py script. This may require waiting through several commits to find a good revision.
  • Update and commit tools/BACKPORTS/VERSIONS to include a line with the hash of your commit as listed in the in the corresponding public Git repo
  • Test the patched toolchains
  • Update the SDK branch (in Chrome) with new toolchain URL
  • Test the new SDK bundle
  • Update the SDK manifest to make the new SDK bundle available
Below we describe these steps in more detail.

Updating the tools/BACKPORTS/VERSIONS

TODO(khim): briefly describe file format, list example codereviews for Git repo, corresponding REVISIONS update, corresponding BACKPORTS/VERSIONS update
TODO(khim): explain when toolchain backports are built (on each commit? on changes in BACKPORTS/VERSIONS?)

Testing the backported toolchains

TODO(khim): explain how to find a backported toolchain for ppapiXX, example link: http://gsdview.appspot.com/nativeclient-archive2/x86_toolchain/r8915@ppapi15/, better write a script, actually
TODO(khim): describe a convenient way for testing the toolchain backports on trybots if such exist (dirty ways are allowed)

Updating the SDK branch in Chrome

TODO(noel): describe or provide a link

Testing the new SDK bundle

TODO(noel): a bunch of shell commands to sanity check a new bundle

Updating the SDK manifest

TODO(noel): describe or provide a link


Comments