Ira Rosen <ira.ro...@linaro.org> writes: > On 9 November 2010 14:38, Andrew Stubbs <[1]...@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 > it? > > Option 1: Launchpad/bzr > > Pros: > ** 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 > ever > ** Our patch tracker will Just Work. > ** Merge requests will be available. > > Cons: > ** Bzr ;) > ** It's hidden away from the view of most GCC developers* > > Option 2: GCC SVN branch > > Pros: > ** 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 > > Cons: > ** 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.
Agreed. 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: svn://gcc.gnu.org/svn/gcc/branches/linaro/ shouldn't be any different from the existing: svn://gcc.gnu.org/svn/gcc/branches/csl/ svn://gcc.gnu.org/svn/gcc/branches/redhat/ svn://gcc.gnu.org/svn/gcc/branches/suse/ svn://gcc.gnu.org/svn/gcc/branches/ix86/ svn://gcc.gnu.org/svn/gcc/branches/ubuntu/ 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. Richard _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
