[LLVMdev] Downstream distributions as first class citizens in the LLVM repository

[Diego Novillo]

On Fri, Oct 18, 2013 at 1:09 PM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:

> This would increase the visibility of changes by any of the vendors
> involved, so that others can pick up the same changes. The impact on
> mailing list traffic should be low as changes are relatively rare
> compared to the rest of the development speed. Code access should follow
> similar practises as release management, e.g. every vendor branch has a
> code owner responsible for it.

This is more or less the model we follow in GCC. Vendor (and, really,
anybody) can create their own branches.
These branches are usually created off of the main release branch for
a particular version.  They are completely under the control of the
third party who created them and they usually contain a few additional
patches over the standard release.

The only requirements for third parties is that they should never
allow a bug in their branch to be filed as a GCC bug unless the same
bug can be reproduced in either trunk or the FSF release branch.

This model has worked well for many years.

At Google, we have a slightly more elaborate branching scheme because
of the amount of work we put in the compiler:

- There is one branch off of trunk (called 'integration') which we use
as a base for internal development. This branch contains a few patches
that are needed to integrate into our build system. These are usually
small changes which either make no sense to anyone else but us, or we
have not yet been able to send upstream. Ideally, this branch should
not exist.

- The branch where we do most of our development is called 'main'. It
contains the bulk of all the changes we make to the compiler for peak
performance in our applications. This branch is a buffer for major
development, which allows us to keep our internal development/release
schedule that is independent from upstream GCC. We are constantly
taking patches out of this branch and proposing them for trunk.

- Release branches.  These branches are created from our 'main' branch
and the current FSF release branch. We use them for our internal
releases. It also acts as a continuous release branch which follows
all the minor releases from the FSF. We are merging changes in the
upstream release branches to get bug fixes and minor feature changes.

All these branches are publicly available from the FSF repository.
I've been in environments where branches are kept behind closed doors.
 They are nothing but a big headache to maintain.


Diego.