When developing a new feature or bugfix for the toolchain, there are two ways to perform the work. In the discussion below, "upstream" refers to the current (GCC) trunk, currently what will become 4.6, and the "local branch" refers to a 4.4 or 4.5-series compiler with local Linaro changes. Note that these compiler versions may differ by one or two years' worth of development work.

Upstream first

The first method is to develop the patch directly on the upstream (FSF) trunk, then backport the patch to the local branch. This has advantages and disadvantages as follows:


  1. You are using current sources. If you are developing a bug fix, you can be pretty sure nobody has fixed it already. If you are developing a feature, you can rely on up-to-date features of the compiler.
  2. When the patch is sent for review, typically many more experienced eyes are available to look over it. It is more likely that a high-quality solution to the problem at hand can be found.
  3. If a patch developed directly upstream is rejected (see disadvantage 2), at least the problem will be fresh in the submitter's mind. That is not necessarily the case for patches developed on local branches.


  1. The upstream review process is driven by volunteers, and can be slow -- sometimes excessively so. Sometimes nobody will review a patch at all, and the submitter of a patch must encourage (often very busy) people to give their patch attention.
  2. Patches can be rejected for arbitrary reasons, or be subject to rewrites. It can take several iterations to get a patch which is considered good enough for upstream (which can take a lot of elapsed time, see disadvantage 1).
  3. To some extent, if a patch is developed for upstream trunk then it may need adaptation to work on an older branch. If a fix is really needed for the older branch, working upstream may not be helpful (this depends on the fix, and on how much the part of the compiler in question has diverged over time).

Local branch first

The second method is to develop a patch on a local branch then submit it upstream at a later date. This also has advantages and disadvantages:


  1. Development can be a lot quicker. If a patch is found which solves the problem/implements the solution and it passes testing and local review, it can be committed to a local repository (even if not fully general/"good enough" for upstream sources). Local reviewers are typically not volunteers, and can be encouraged to review patches which upstream volunteers might not be interested in, but may not be as widely versed in various parts of the compiler as upstream maintainers.
  2. Local branches don't necessarily need FSF copyright assignment. Sometimes such an assignment is not available for 3rd-party patches.
  3. Often a bug report will be against a particular compiler version, and so it's generally sensible to work against the same compiler version when developing a fix: that way, the original bug reporter will generally get the fix a lot sooner (and you can be fairly sure that it'll be possible to reproduce the breakage using a compiler which is very similar to the reporter's, which is usually a vital step in tracking down a bug -- sometimes other unrelated changes in the compiler will hide the presence of a bug in a later version for a given test case, even if the bug is actually still present).


  1. Local branches may fall behind upstream branches, meaning that the work of producing the patch may need to essentially be done twice. The problem gets worse the longer upstream submission is delayed.
  2. Because upstream maintainers do not see the patch, sometimes a better (cleaner, more general) solution may be missed.
  3. The "extra" work needed to get the patch upstream generally needs to be done eventually anyway.

Backporting patches

Backporting patches is generally considered harder than forward-porting them. We suggest that a given patch should be backported first to the earliest branch to which it applies, then be successively forward-ported to newer branches, so it is eventually present on as many branches as possible.

WorkingGroups/ToolChain/Development (last modified 2010-06-18 17:07:25)