launchpad / merge requests and upstreaming patches.

[Richard Sandiford]

Ramana Radhakrishnan <ramana.radhakrishnan at linaro.org> writes:
> On 29 November 2011 12:04, Richard Sandiford
> <richard.sandiford at linaro.org> wrote:
>> Ramana Radhakrishnan <ramana.radhakrishnan at 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