Mark Mitchell <m...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
