ams at codesourcery.com
Fri Aug 13 11:00:28 BST 2010
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 ...".
More information about the Linaro-dev