Patch tracking

[Andrew Stubbs]

On 13/08/10 10:08, Amit Kucheria wrote:
> On 10 Aug 13, Michael Hope wrote:
>> On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria<amit.kucheria at linaro.org>  wrote:
>>> So git-based workflows won't benefit from this then?
>>
>> There's no particular dependence on any VC system.  I will be making a
>> report on each bzr commit to make sure there is a corresponding ticket
>> that tracks the upstream state.
>
> Sounds tedious. It probably isn't, so I'll wait for you to post your results.

Tedious, yes, but there's no real way around that. We're planning to do 
everything possible to reduce the work, but in the end, somebody has to 
make a note "merge done here ..", or "merge not done because ..".

The idea is that an automated tool reads bzr log output (or git log 
output) and uses the launchpad API to create a ticket for each, seeded 
with as much info as it knows, and assigns it to the committer.

Having no manual step in starting the tracking process means no initial 
tedium, and no patches fall through the cracks.

If the patch has not been merged upstream, there's no further manual 
step to do, and the system tracks until forever that the patch exists 
and needs merging on rebase (this is a bigger deal in some projects than 
others, of course), and also indicates that you really should be doing 
something about it.

If the patch has been merged, or will never be merged, or whatever, then 
somebody can manually change the state, and again, we know what we need 
to do on rebase.

In the meantime, we can use the ticket to record whatever interesting 
information there might be regarding this patch: "awaiting ...", "sent 
for review here ...", "maybe I'll do this a different way ...".

Andrew