Hi All,
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but maybe it could go on a cron job somewhere in future.
The idea is that people write useful thing in this page manually, as and when state changes. If we don't do something like this, we'll lose track of what's submitted, and what isn't.
Thanks
Andrew
On Wed, Jul 14, 2010, Andrew Stubbs wrote:
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
Excellent! Very elegant update process too. I wonder whether we could check more with bzr.
We also need to track status in Linaro GCC 4.5.
I had put it on the sprint agenda to discuss this https://wiki.linaro.org/Internal/Events/2010-07-PlatformSprint/ToolChainWG#P...
Andrew Stubbs ams@codesourcery.com wrote:
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but maybe it could go on a cron job somewhere in future.
The idea is that people write useful thing in this page manually, as and when state changes. If we don't do something like this, we'll lose track of what's submitted, and what isn't.
Good idea. What should the status be for patches that are themselves backports from mainline, like e.g. "Fix LP bug #602289" ?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
For information on how to authenticate against the wiki using your Firefox cookie, see: http://www.mail-archive.com/oem-qa@lists.launchpad.net/msg00002.html
-- Michael
On Thu, Jul 15, 2010 at 3:54 AM, Andrew Stubbs ams@codesourcery.com wrote:
Hi All,
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but maybe it could go on a cron job somewhere in future.
The idea is that people write useful thing in this page manually, as and when state changes. If we don't do something like this, we'll lose track of what's submitted, and what isn't.
Thanks
Andrew
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
This is exactly what I've done. :)
On 14/07/10 21:46, Michael Hope wrote:
For information on how to authenticate against the wiki using your Firefox cookie, see: http://www.mail-archive.com/oem-qa@lists.launchpad.net/msg00002.html
-- Michael
On Thu, Jul 15, 2010 at 3:54 AM, Andrew Stubbsams@codesourcery.com wrote:
Hi All,
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but maybe it could go on a cron job somewhere in future.
The idea is that people write useful thing in this page manually, as and when state changes. If we don't do something like this, we'll lose track of what's submitted, and what isn't.
Thanks
Andrew
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Andrew Stubbs wrote:
Hi All,
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but maybe it could go on a cron job somewhere in future.
This scrip is great.
Some questions on upstream merge process,
1. How to do tests to these patches. We should apply each of these patches to gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch, and bootstrap. If this patch is target-specific, shall we build a cross-compiler to test on target board or qemu, or build native compiler on target machine directly? As Loic suggested, in ubuntu, we choose latter approach. Any ARM board that we can access?
2. How to deal with patches for PR fix, such as pr39429.diff pr41848.diff pr43323.diff pr40133.diff, etc. We should send updated patches to gcc-patches. Shall we update gcc bugzilla accordingly? say "latest patch is posted somewhere in gcc-patches"
3. Some patches was discussed before in gcc-patches, shall we start a new thread on the patch discussion or go on in the old thread.
Finally, If there is a reference that ubuntu patch goes to upstreams, please give me a link, that will be pretty useful for me.
The idea is that people write useful thing in this page manually, as and when state changes. If we don't do something like this, we'll lose track of what's submitted, and what isn't.
Thanks
Andrew
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 15/07/10 09:59, Yao Qi wrote:
- How to do tests to these patches. We should apply each of these
patches to gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch, and bootstrap. If this patch is target-specific, shall we build a cross-compiler to test on target board or qemu, or build native compiler on target machine directly? As Loic suggested, in ubuntu, we choose latter approach. Any ARM board that we can access?
Patches are always submitted to the upstream mainline. In this case, what will be GCC 4.6.
In any case, upstream don't accept fixes to release branches unless they fix regressions (i.e. something that used to work in 4.3, but is broken in 4.4), and even then, it normally has to be a backport from mainline.
- How to deal with patches for PR fix, such as pr39429.diff
pr41848.diff pr43323.diff pr40133.diff, etc. We should send updated patches to gcc-patches. Shall we update gcc bugzilla accordingly? say "latest patch is posted somewhere in gcc-patches"
If we fix something in GCC bugzilla we should update bugzilla. The patch can be posted to either gcc-patches, or to bugzilla directly, although I think the former is preferred. Putting a reference in the bug is entirely appropriate.
- Some patches was discussed before in gcc-patches, shall we start a
new thread on the patch discussion or go on in the old thread.
Start a new one, if the old one is very old, and include a link to the historical discussion.
If the patch is already upstream (albeit not in 4.4), then there's nothing to do. I suspect this it the case for all the prXXXX patches - we just need to update the tracker.
Andrew
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
Loïc Minier -
Michael Hope -
Ulrich Weigand -
Yao Qi