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.kuche...@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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
