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 * 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. * 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.
Andrew
On 9 November 2010 14:38, Andrew Stubbs ams@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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 09/11/10 12:55, Ira Rosen wrote:
* We can't really apply anything we want just for ourselvesWhy? 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.
Applying patches that are not intended to go upstream would defeat the object of easing the merge. We'd need to revert all those bits before merging. It'd be clearer and easier to commit the individual patches we do want upstream one at a time when the time comes.
* Write permissions not clear.Do you mean we have people without GCC write-after-approval permissions?
Well, yes, but I'm assuming there aren't many of those. The question that was raised what about who is permitted to add junk into the GCC repo. I believe that it's not a problem, but I'm not certain. There's also the question of what the assignment status of patches on branches needs to be?
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 ;)
I don't think I said it had to be? My point is that numbered Linaro GCC releases really ought to be tagged in a LP branch somewhere. This is simply good practice, and not about stability. My 'unstable' comment was merely pointing out that pre-4.6.0 snapshots should not be marketed as trusted, high-quality releases.
Andrew
On 9 November 2010 15:36, Andrew Stubbs ams@codesourcery.com wrote:
On 09/11/10 12:55, Ira Rosen wrote:
* We can't really apply anything we want just for ourselvesWhy? 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.
Applying patches that are not intended to go upstream would defeat the object of easing the merge. We'd need to revert all those bits before merging. It'd be clearer and easier to commit the individual patches we do want upstream one at a time when the time comes.
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 (or express their opinions) without asking them to do that explicitly during early stage 3.
I understand that it's my developer's point of view and it doesn't make branch/release management easier (as Richard mentioned in his mail). But since our goal is to commit everything upstream (right?), I think we should try to make the review of our patches it as easy as possible. And having an SVN branch is a good way to do so. Branch merge is in our hands, and even if it's a lot of work, we don't depend on other people as with patches' approval.
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 ;)
I don't think I said it had to be? My point is that numbered Linaro GCC releases really ought to be tagged in a LP branch somewhere. This is simply good practice, and not about stability. My 'unstable' comment was merely pointing out that pre-4.6.0 snapshots should not be marketed as trusted, high-quality releases.
I see. Thanks for the explanation.
Ira
Andrew
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 (or express their opinions) without asking them to do that explicitly during early stage 3.
I agree with this statement. My understanding is that a goal for Linaro is to work upstream as fully as possible, and if that is the case then I think an upstream SVN branch is the best way to do that. It's also the simplest for an upstream GCC developer coming to work on Linaro.
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).
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 should also be considered
I found Andrew's summary of Pros and Cons a much better base for discussion
There might also be other options which don't require a choice, like exporting the Bazaar data into a read-only SVN branch for upstream's convenience -- upstream can see and access the data in their preferred format and we can keep existing practices
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 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? 2. Can we host the consolidation branch (the one we do monthly releases from) in SVN as well?
(1) is a deal breaker. What are peoples experiences with the SVN version used on the GCC servers?
Andrew, could you look into (2) please? We need to have an authoritative answer from the GCC overseers or to assume 'no'.
-- Michael
On Wed, Nov 10, 2010 at 5:03 AM, Loïc Minier loic.minier@linaro.org wrote:
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 should also be considered
I found Andrew's summary of Pros and Cons a much better base for discussion
There might also be other options which don't require a choice, like exporting the Bazaar data into a read-only SVN branch for upstream's convenience -- upstream can see and access the data in their preferred format and we can keep existing practices
-- Loïc Minier
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
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.
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
I don't have the list, but I remember Andrew mentioning this for some of the useful patches we merged
(there was also a debate on the risk of contamining code we'd like to upstream with this non-assigneable code, so maybe we reverted these)
On 17/11/10 03:35, Michael Hope wrote:
There's two open questions:
- 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 be equivalent to bzr merging (within SVN's somewhat different concept of branching), and should do the job nicely.
See http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html
It does not appear to require all users to have version 1.5, but all the users doing merges must have it. (I use version 1.6.12, at present).
- Can we host the consolidation branch (the one we do monthly
releases from) in SVN as well?
As Mark said, creating the branch is not a problem as long as all our patches are free of legal issues.
Andrew
On 17/11/10 09:57, Andrew Stubbs wrote:
On 17/11/10 03:35, Michael Hope wrote:
There's two open questions:
- 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 be equivalent to bzr merging (within SVN's somewhat different concept of branching), and should do the job nicely.
Oh, I should say, neither SVN merge, nor BZR merge will work for merging *to* trunk. (Both will be suitable for merging *from* trunk.)
Doing a merge like that will a) flatten all the patches into one monster patch, and b) include all the other bits and pieces you don't want on the main trunk (release version numbers, etc).
Obviously, there are ways to work around these issues, but I'm just saying that a straight merge probably isn't what you want.
Andrew
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 still need the license and copyright assignment sorted out
This leaves us the visibility problem, and that it's hard for other GCC developers to pick up our branch and play with it. Let's discuss these at today's meeting.
It's a good time to talk about Bazaar as well. I've started the page: https://wiki.linaro.org/MichaelHope/Sandbox/BzrIssues
Please record any specific issues, with enough detail to reproduce them, on the page. I'll consolidate the problems and get them fixed.
-- Michael
On Thu, Nov 18, 2010 at 3:52 AM, Andrew Stubbs ams@codesourcery.com wrote:
On 17/11/10 09:57, Andrew Stubbs wrote:
On 17/11/10 03:35, Michael Hope wrote:
There's two open questions:
- 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 be equivalent to bzr merging (within SVN's somewhat different concept of branching), and should do the job nicely.
Oh, I should say, neither SVN merge, nor BZR merge will work for merging *to* trunk. (Both will be suitable for merging *from* trunk.)
Doing a merge like that will a) flatten all the patches into one monster patch, and b) include all the other bits and pieces you don't want on the main trunk (release version numbers, etc).
Obviously, there are ways to work around these issues, but I'm just saying that a straight merge probably isn't what you want.
Andrew
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 good if we kept working with bzr, but we pushed to svn (via bzr-svn) nightly? Whenever some non-Linaro person sends a patch against SVN, it should apply equally well on top of bzr
Ira Rosen ira.rosen@linaro.org writes:
On 9 November 2010 14:38, Andrew Stubbs <[1]ams@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@lists.linaro.org
-
Andrew Stubbs -
Ira Rosen -
Loïc Minier -
Mark Mitchell -
Michael Hope -
Richard Sandiford