Hi all,
As you may or may not know, upstream GCC has now entered 'stage 3' of it's development cycle. This will last until spring.
This means that they are only accepting bug fixes and documentation improvements. New features and any performance improvements must wait until GCC 4.6 branches, prior to release, and GCC 4.7 development opens.
During this process, our usual preferred work flow (upstream first) will not work, so we'll have to do something else.
Here's my proposal:
* Create a new Launchpad branch for GCC 4.6.
* Synchronize this branch with upstream regularly * once per week, perhaps.
* Try to get upstream approval for all new patches in the usual way * on the understanding that they won't be applied until stage 1 * bug fixes are unaffected and may commit as usual.
* Commit all pending patches to our own 4.6 branch * and backport them to our 4.5, branch, of course.
* Usual "no test regressions" policy applies to our own patches * but beware regressions from merges from upstream. * we may want to track the clean 4.6 test results for comparison
This is little different to what we do with the 4.5 release branch now.
Thoughts?
Andrew
On 11/08/2010 07:01 PM, Andrew Stubbs wrote:
Hi all,
As you may or may not know, upstream GCC has now entered 'stage 3' of it's development cycle. This will last until spring.
This means that they are only accepting bug fixes and documentation improvements. New features and any performance improvements must wait until GCC 4.6 branches, prior to release, and GCC 4.7 development opens.
Yeah, most of our GCC development work, like speed/size improvement, auto-vect, and so forth, can not be in GCC mainline 4.6 until 'stage 3' is over.
During this process, our usual preferred work flow (upstream first) will not work, so we'll have to do something else.
Here's my proposal:
Create a new Launchpad branch for GCC 4.6.
Synchronize this branch with upstream regularly
- once per week, perhaps.
In this situation, this LP GCC 4.6 branch can be regarded as our upstreams at that moment.
- Try to get upstream approval for all new patches in the usual way
- on the understanding that they won't be applied until stage 1
- bug fixes are unaffected and may commit as usual.
Will reviewers/maintainers still review patches unrelated on documentation fix and bug fix in stage 3? If patches still can be reviewed in time, that is not a problem.
Commit all pending patches to our own 4.6 branch
- and backport them to our 4.5, branch, of course.
Usual "no test regressions" policy applies to our own patches
- but beware regressions from merges from upstream.
Shall we fix regressions from merges from upstreams in our own 4.6 tree? Is our criteria to fix regressions only if we are blocked by them?
- we may want to track the clean 4.6 test results for comparison
This is little different to what we do with the 4.5 release branch now.
I think we need this process.
On 11/8/2010 7:22 AM, Yao Qi wrote:
In this situation, this LP GCC 4.6 branch can be regarded as our upstreams at that moment.
- Try to get upstream approval for all new patches in the usual way
- on the understanding that they won't be applied until stage 1
- bug fixes are unaffected and may commit as usual.
Will reviewers/maintainers still review patches unrelated on documentation fix and bug fix in stage 3?
Some will; some prefer not to do so. Obviously, as you get closer to the release, upstream maintainers tend to become more focused on the release. You can also look for situations where the change you are making is fixing a regression from a previous release, as that will sometimes persuade an upstream maintainer to consider your change a "bug fix" even if it is more substantial. There is obviously a lot of judgment required in determining what is a bug fix and what is a new feature.
In short, I still think it's a good idea to send things upstream. You will often get at least a partial review of the form "perhaps this could be done in this existing pass?" or "you might consider doing it this way instead" or "that looks pretty good!".
Mark Mitchell mark@codesourcery.com writes:
On 11/8/2010 7:22 AM, Yao Qi wrote:
In this situation, this LP GCC 4.6 branch can be regarded as our upstreams at that moment.
- Try to get upstream approval for all new patches in the usual way
- on the understanding that they won't be applied until stage 1
- bug fixes are unaffected and may commit as usual.
Will reviewers/maintainers still review patches unrelated on documentation fix and bug fix in stage 3?
Some will; some prefer not to do so. Obviously, as you get closer to the release, upstream maintainers tend to become more focused on the release. You can also look for situations where the change you are making is fixing a regression from a previous release, as that will sometimes persuade an upstream maintainer to consider your change a "bug fix" even if it is more substantial. There is obviously a lot of judgment required in determining what is a bug fix and what is a new feature.
In short, I still think it's a good idea to send things upstream. You will often get at least a partial review of the form "perhaps this could be done in this existing pass?" or "you might consider doing it this way instead" or "that looks pretty good!".
I agree. One option that Andrew suggested at the meeting was to put the branch in GCC SVN instead of Launchpad. That sounded like a good idea to me. It's usual (maybe even expected) that people who maintain their own SVN branches post the patches they're committing to gcc-patches, so I don't think we could be accused of spamming the list or asking for anything inappropriate.
I just have a feeling that having an SVN branch would go more smoothly than posting patches to the list but maintaining them elsewhere.
Richard
On 2010/11/8 下午 07:01, Andrew Stubbs wrote:
Here's my proposal:
Create a new Launchpad branch for GCC 4.6.
Synchronize this branch with upstream regularly
- once per week, perhaps.
Try to get upstream approval for all new patches in the usual way
- on the understanding that they won't be applied until stage 1
- bug fixes are unaffected and may commit as usual.
Commit all pending patches to our own 4.6 branch
- and backport them to our 4.5, branch, of course.
Usual "no test regressions" policy applies to our own patches
- but beware regressions from merges from upstream.
- we may want to track the clean 4.6 test results for comparison
This is little different to what we do with the 4.5 release branch now.
This looks fine, it actually isn't that much different from what we're doing now, except using another branch to hold our changes.
Still, I would like to see a 'linaro-trunk' branch under svn://gcc.gnu.org/svn/branches. It would actually serve a different purpose than a LP branch; the LP GCC 4.6 would probably eventually turn into Linaro 4.6, while a SVN branch would be a preparation for re-merging into mainline trunk when 4.7-stage1 opens. Also, for the GCC community, a SVN branch would probably be more convenient.
We can have our patches submitted to gcc-patches, and have it reviewed under the usual [patch, <branch>] format, rather than the odd condition where we ask for approval, then accumulate in an outside repository.
Chung-Lin
On 8 November 2010 20:30, Chung-Lin Tang cltang@codesourcery.com wrote:
Still, I would like to see a 'linaro-trunk' branch under svn:// gcc.gnu.org/svn/branches. It would actually serve a different purpose than a LP branch; the LP GCC 4.6 would probably eventually turn into Linaro 4.6, while a SVN branch would be a preparation for re-merging into mainline trunk when 4.7-stage1 opens. Also, for the GCC community, a SVN branch would probably be more convenient.
We can have our patches submitted to gcc-patches, and have it reviewed under the usual [patch, <branch>] format, rather than the odd condition where we ask for approval, then accumulate in an outside repository.
On 8 November 2010 20:17, Richard Sandiford richard.sandiford@linaro.orgwrote:
I agree. One option that Andrew suggested at the meeting was to put the branch in GCC SVN instead of Launchpad. That sounded like a good idea to me. It's usual (maybe even expected) that people who maintain their own SVN branches post the patches they're committing to gcc-patches, so I don't think we could be accused of spamming the list or asking for anything inappropriate.
I just have a feeling that having an SVN branch would go more smoothly than posting patches to the list but maintaining them elsewhere.
I also think that an SVN branch is a better idea than Launchpad, and I agree with both Chung-Lin's and Richard's arguments.
Ira
I agree on the approach. I'm concerned about moving over to SVN for a few reasons: duplication of accounts (however most of the WG already have or will need sourceware.org accounts), harder merging (with bzr you do a 'bzr merge lp:gcc' and it does a good, three way merge with trunk. Last time I used svn for this it was a mess), needing write approval (perhaps mitigated by having our own /linaro playground), and making our code easy for third parties to find.
One approach would be: * Work in svn://trunk while in stage 1 * Work in svn://linaro/trunk while in stage 3 * Keep lp:gcc-linaro as our consolidation branch * Use the Launchpad lp:gcc import to make merging the changes into the consolidation branch easier
This keeps development upstream and keeps the consolidation branch in the same place.
Andrew, could you contact the sourceware overseers, introduce us, ask about the account policies, and getting a linaro directory for us to work in?
-- Michael
On Tue, Nov 9, 2010 at 8:33 AM, Ira Rosen ira.rosen@linaro.org wrote:
On 8 November 2010 20:30, Chung-Lin Tang cltang@codesourcery.com wrote:
Still, I would like to see a 'linaro-trunk' branch under svn://gcc.gnu.org/svn/branches. It would actually serve a different purpose than a LP branch; the LP GCC 4.6 would probably eventually turn into Linaro 4.6, while a SVN branch would be a preparation for re-merging into mainline trunk when 4.7-stage1 opens. Also, for the GCC community, a SVN branch would probably be more convenient.
We can have our patches submitted to gcc-patches, and have it reviewed under the usual [patch, <branch>] format, rather than the odd condition where we ask for approval, then accumulate in an outside repository.
On 8 November 2010 20:17, Richard Sandiford richard.sandiford@linaro.org wrote:
I agree. One option that Andrew suggested at the meeting was to put the branch in GCC SVN instead of Launchpad. That sounded like a good idea to me. It's usual (maybe even expected) that people who maintain their own SVN branches post the patches they're committing to gcc-patches, so I don't think we could be accused of spamming the list or asking for anything inappropriate.
I just have a feeling that having an SVN branch would go more smoothly than posting patches to the list but maintaining them elsewhere.
I also think that an SVN branch is a better idea than Launchpad, and I agree with both Chung-Lin's and Richard's arguments.
Dnia wtorek, 9 listopada 2010 o 00:09:03 Michael Hope napisał(a):
I agree on the approach. I'm concerned about moving over to SVN for a few reasons:
harder merging (with bzr you do a 'bzr merge lp:gcc' and it does a good, three way merge with trunk. Last time I used svn for this it was a mess),
If you like Bazaar you can use "bzr-svn" to manage Subversion repository with bzr tools. Same for GIT users with "git-svn".
I do not remember when last time I used svn directly - always prefer "git-svn" for it.
Regards,
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
Chung-Lin Tang -
Ira Rosen -
Marcin Juszkiewicz -
Mark Mitchell -
Michael Hope -
Richard Sandiford -
Yao Qi