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