Thanks everyone for your input. We'll keep the Linaro GCC 4.6 work on
Launchpad/Bazzar, mainly for the following reasons:
1. Bazzar's merging is much easier and more reliable
2. Good integration with a bug tracker, blueprints, and release system
3. Ability to host early versions of patches that
Hi,
On 17 November 2010 05:35, Michael Hope wrote:
> 1. How easy is it to frequently merge in SVN? It used to be terrible
> as you had to manually track the merges. These days can you do a 'svn
> merge trunk' and have it just work?
I asked Mike Meissner to answer this question. Mike is very ex
On 17/11/10 09:57, Andrew Stubbs wrote:
On 17/11/10 03:35, Michael Hope wrote:
There's two open questions:
1. How easy is it to frequently merge in SVN? It used to be terrible
as you had to manually track the merges. These days can you do a 'svn
merge trunk' and have it just work?
Subversion 1
On Wed, Nov 17, 2010, Michael Hope wrote:
> https://wiki.linaro.org/MichaelHope/Sandbox/GCC46Hosting
> They're the same on the technical side, Launchpad wins on the release
> side, and SVN wins on the community side.
Maybe this has been considered, but I'll just double-check :-)
would it be g
On Tue, Nov 16, 2010, Mark Mitchell wrote:
> GCC policy is simple: you can host any branch you want in GCC SVN, so
> long as all the code is assigned to the FSF.
ah but at some point we have merged some CS patches which are not
necessarily assigned to the FSF because they came via third parties
On 17/11/10 03:35, Michael Hope wrote:
There's two open questions:
1. How easy is it to frequently merge in SVN? It used to be terrible
as you had to manually track the merges. These days can you do a 'svn
merge trunk' and have it just work?
Subversion 1.5 supports merging that appears to b
On 11/16/2010 7:35 PM, Michael Hope wrote:
> Andrew, could you look into (2) please? We need to have an
> authoritative answer from the GCC overseers or to assume 'no'.
GCC policy is simple: you can host any branch you want in GCC SVN, so
long as all the code is assigned to the FSF.
--
Mark Mi
Here's my summary based on these emails and the Monday call:
https://wiki.linaro.org/MichaelHope/Sandbox/GCC46Hosting
They're the same on the technical side, Launchpad wins on the release
side, and SVN wins on the community side.
There's two open questions:
1. How easy is it to frequently merge
On Tue, Nov 09, 2010, Mark Mitchell wrote:
> So, fundamentally, we have to choose whether we want to work as much as
> possible upstream (using an SVN branch), or whether we want uniformity
> across Linaro projects (using Launchpad).
This only lists political options; the quality of the tool shou
On 11/9/2010 6:11 AM, Ira Rosen wrote:
> I don't believe we will be able to get all the patches pre-approved and
> maintain a pure linaro-trunk anyway. For me the main value of SVN branch
> is an ability to make my work visible to GCC community and give them an
> opportunity to review the patches
On 9 November 2010 15:36, Andrew Stubbs wrote:
> On 09/11/10 12:55, Ira Rosen wrote:
>
>> * 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/
Ira Rosen 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
On 09/11/10 12:55, Ira Rosen wrote:
* 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 [] and
On 9 November 2010 14:38, Andrew Stubbs 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
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 br
15 matches
Mail list logo
