GCC SVN vs. BZR/LP

[Ira Rosen]

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 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.


>   * we may end up maintaining an LP branch shadowing the svn branch
>  * When we do want to do 4.6 in LP, we'll have to backport all our patches
> from 4.7, and this may no longer be straightforward.
>  * Write permissions not clear.
>

Do you mean we have people without GCC write-after-approval permissions?


>   * Although I think you can just go ahead and do it?
>
> OK, so I'm sure I've missed some big ones. Please discuss! ;)
>
> I think the big question here is, when will we start wanting to make
> (unstable/experimental) Linaro GCC 4.6 releases? If we want to do it early,
> then we'll have no choice but to have an LP branch to release from.
>

Again, I don't understand why our SVN branch needs to be stable ;)

Ira


>
> Andrew
>
> _______________________________________________
> linaro-toolchain mailing list
> linaro-toolchain at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-toolchain/attachments/20101109/7afd8bdc/attachment.html>