GCC SVN vs. BZR/LP
richard.sandiford at linaro.org
Tue Nov 9 13:44:51 UTC 2010
Ira Rosen <ira.rosen at linaro.org> writes:
> On 9 November 2010 14:38, Andrew Stubbs <ams at codesourcery.com> wrote:
> Re my recent email "Upstream GCC feature freeze", I think we're agreed
> that we need to create a branch that tracks GCC 4.6 development, but has
> our own performance improvements included. The question is where to host
> Option 1: Launchpad/bzr
> ** We need no permission to do it
> ** The branch will naturally evolve into our 4.6 release series in time.
> ** The 3-way merge works well (if slowly)
> ** We can include patches that we have no intention of posting upstream
> ** Our patch tracker will Just Work.
> ** Merge requests will be available.
> ** Bzr ;)
> ** It's hidden away from the view of most GCC developers*
> Option 2: GCC SVN branch
> ** We can work in the open, submitting patches via gcc-patches, as usual
> ** The final merge to GCC trunk (come stage 1) will be eased, a little
> ** We can't really apply anything we want just for ourselves
> Why? It will be our "private" Linaro branch. We can apply whatever we want
> there (we can also decide on reviewers and/or some submit/commit
> procedure). We can mark our patches with both [<our branch name>] and
> [4.7] when we send them to gcc-patches.
Also, as far as permissions go: we don't need any permission to create a
GCC SVN branch (or indeed several branches, if we wanted a separate 4.6
and trunk branch at some point). Anyone with SVN write access is allowed
to do that without prior permission.
I think we can still apply patches to an SVN branch that we don't want
to submit to mainline, including customisation patches such as changing
the bug reporting address. Of course, if we're maintaining patches that
we don't want to submit back, we'd need to remember which ones they are
when submitting the others, but that's true whereever we host the branch.
I think the only restriction is that the copyright needs to be assigned
to the FSF.
FWIW, there's a fair bit of precedent. Having:
shouldn't be any different from the existing:
although admittedly only redhat/ and ix86/ are actively used now.
That probably comes across a bit strong, sorry. Obviously whichever
way we choose will work. It's just that, from a developer's point
of view, I do see a lot of advantages in the SVN approach. I realise
things might look different from a release management point of view.
More information about the linaro-toolchain