Hi,
Now that upstream trunk is in stage3 and we have a few patches that won't really make it upstream until stage1 is reopened is it worthwhile having a new status in the merge requests that moves it into a to_upstream status . The other option is to have a common spreadsheet that we keep updating with links to merge requests that need to be upstreamed .
Thoughts ?
Ramana
PS - Any clue on what's happening with the branch diff bug that's been open in launchpad forever now ?
Ramana Radhakrishnan ramana.radhakrishnan@linaro.org writes:
Now that upstream trunk is in stage3 and we have a few patches that won't really make it upstream until stage1 is reopened is it worthwhile having a new status in the merge requests that moves it into a to_upstream status . The other option is to have a common spreadsheet that we keep updating with links to merge requests that need to be upstreamed .
Bikeshedding a little here, but TBH, I preferred your suggestion in Ira's merge request that we mark the ChangeLog.linaro entries instead.
Richard
On 29 November 2011 12:04, Richard Sandiford richard.sandiford@linaro.org wrote:
Ramana Radhakrishnan ramana.radhakrishnan@linaro.org writes:
Now that upstream trunk is in stage3 and we have a few patches that won't really make it upstream until stage1 is reopened is it worthwhile having a new status in the merge requests that moves it into a to_upstream status . The other option is to have a common spreadsheet that we keep updating with links to merge requests that need to be upstreamed .
Bikeshedding a little here, but TBH, I preferred your suggestion in Ira's merge request that we mark the ChangeLog.linaro entries instead.
True, I originally thought about this and I wondered if we could tie down the actual rev-id in some form but there's no reason why we can't find that from a bit of scripting magic - essentially a bzr blame giving us revision IDs that introduced something not going upstream. We would then always have to remember to remove it from Changelog.linaro once it has been merged upstream to reflect that status.
Instead of having these many steps - I thought it might be easier to maintain this information out of Changelog.linaro either with one of the Status fields in the original merge request itself or in a separate spreadsheet. Whatever works best for everyone is fine with me.
cheers Ramana
Richard
Ramana Radhakrishnan ramana.radhakrishnan@linaro.org writes:
On 29 November 2011 12:04, Richard Sandiford richard.sandiford@linaro.org wrote:
Ramana Radhakrishnan ramana.radhakrishnan@linaro.org writes:
Now that upstream trunk is in stage3 and we have a few patches that won't really make it upstream until stage1 is reopened is it worthwhile having a new status in the merge requests that moves it into a to_upstream status . The other option is to have a common spreadsheet that we keep updating with links to merge requests that need to be upstreamed .
Bikeshedding a little here, but TBH, I preferred your suggestion in Ira's merge request that we mark the ChangeLog.linaro entries instead.
True, I originally thought about this and I wondered if we could tie down the actual rev-id in some form but there's no reason why we can't find that from a bit of scripting magic - essentially a bzr blame giving us revision IDs that introduced something not going upstream. We would then always have to remember to remove it from Changelog.linaro once it has been merged upstream to reflect that status.
Well, I thought we'd still be developing patches against upstream first, and those patches will often differ from 4.6 in some way, so I thought most people would have separate "upstream" copies of each patch lying around. I wasn't planning on pulling 4.6 patches out of bzr and working from there.
If that's true, then I was thinking it would just be one step: update ChangeLog.linaro once the patch is upstream.
Richard
linaro-toolchain@lists.linaro.org
-
Ramana Radhakrishnan -
Richard Sandiford